When the bitmap needs extending, 'vol->free_mft_records' is incremented
by 8*8=64 records. This is due to the bitmap's initialized area being
extended 8 bytes at a time.
However the way 'vol->free_mft_records' is being initialized is that all
the bits that are currently allocated to the MFT bitmap are already
taken into account at initialization time. This leads to a value for
'vol->free_mft_records' that is larger than the actual available number
of MFT records.
For example if there are 20 used MFT records and the bitmap has a 4096
byte allocation where 16 bytes are initialized, the number of free MFT
records are ((8 * 16) - 20) + (8 * (4096 - 16)) = 32748 records
available.
If we now expand the bitmap by 8 initialized bytes, we'd be adding 64
MFT entries according to the logic in the function
'ntfs_mft_bitmap_extend_initialized'.
However we are expanding it within the bounds of the existing allocation
where there is (4096 - 16) bytes free, so they shouldn't be added at all
at this stage.
The result is that our internal accounting is that we have 32748 + 64 =
32812 available MFT records, but in reality we will have 32748 records
available all the time until we expand the allocation beyond 4096 bytes.
Fixed by incrementing 'vol->free_mft_records' when the allocation is
expanded, not when the initialized size is.
When creating a new MFT record, the former seq_no and usn are retrieved
to avoid the new one to be mistaken for the former one.
This may not be possible when the record is used for the first time
or after some bad error. In such situation use default values.
Checked that attributes are [non-]resident when they have to be, and
grouped consistency checks on each of them in a dedicated function.
Consequenly request the checks where needed and remove existing index
checks.
Reject updating uninitialized MFTMirr because it leads to endless
recursions as updating the MFTMirr entry of MFT implies further updating
MFTMirr.
This is probably specific to ntfsfix, as mounts are normally rejected
when MFTMirr does not match MFT.
When extents are needed to store the runlist of the MFT, the first one
must be located in record 15 so that its location can be determined from
the part in the base extent. As this record is always marked in use,
determining whether it is not really in use requires a specific logic.
When creating a new MFT record, do not issue a warning if the current
record has bad fixups. These warnings are meaningless, difficult to
interpret and cause unneeded worries.
An unused MFT record may show a bad length, leading to fetch fixups from
unallocated memory when allocating the record to a new file. So check
the length before applying the fixups. Such records have been found after
the MFT has been reallocated by a defragmenter, and they are not cleaned
by chkdsk.
When the runlist of the data attribute of MFT has to be split across
several extents, the location of each extent has to be known from the
runlist present in previous extents. So, force the first extent into
record 15 to avoid a bad layout.
Logging of fixup errors for uninitialized inodes cause unnecessary
worries and suspicion of malfunctions in ntfs-3g. This patch silences
these loggings in ntfsclone and ntfsresize which have to analyze all
inodes, including the uninitialized ones.
Erik Larsson
Jean-Pierre André
Jean-Pierre André
Erik Larsson
jpandre
szaka