From Windows 10 Creators edition, the cluster size limit has been
extended to 2MB. This has implied redefining the boot sector field
"sectors_per_cluster" so that values greater than 128 can be recorded.
When trying a resize in "no action" (read-only) mode, and the MFT runlist
has to be reorganized to take its new fragmentation into account, the updated
runlist cannot be read from the device while updating the runlist of
normal files. To avoid having to read the updated runlist, the update
is delayed so that the original runlist is used. As a consequence the test
of reorganizing the runlists is only an approximation of what would happen
in a real resize.
The bad cluster list may be updated in ntfsresize and ntfsfix. Though
technically it is organized as a sparse file, Windows does not set
the sparse flags. Do the same to avoid problems with third-party
packages.
Closing the volume is the way to sync the MFT to disk. When not doing
so, the MFT runlists in $DATA and $Bitmap are not synced if they have
been updated in the second resizing stage relative to runlists which
have grown outside their original MFT record.
Unlike in most cases, the bad sector inode has to be closed if it
was updated and required MFT extents (when there are a lot of bad
sectors and some of them were outside the truncated partition).
Not doing so causes the inode to not be fully synced to device.
This fixes the case where the original bad cluster list requires extents.
The list is processed globally, no relocation is done, and the list is
truncated, possibly fitting into fewer extents.
When the bad cluster list required extent, ntfsclone and ntfsresize
did not process the extents, leading to unexpected read errors and
unmatching bitmaps. This fix enables the full list to be taken into
account.
The MFT has two runlists which may be partially stored in extents.
When these runlists have to be relocated, the relocations must be done
after the old runlists are not needed any more to read the data of
standard files, but before the MFT may be needed to extend the runlists
of standard files. Before doing so the MFT runlists have to be refreshed
from device in order to collect the updates which cannot be done in
memory during the first stage.
The ntfsprogs used to return failure when option --version or --help
was used, and this has triggered complains from distribution packagers
who use these options in packaging scripts.
With this patch, success is returned (same behavior as gcc).
When the partition is resized, the global bitmap size is adjusted accordingly,
however so far the new size was not set into the parent index (only minor
consequences).
In some rare situations relocated runlists are longer than the original
ones and do not fit into the same extent. When this happens the runlist
updating is delayed and done globally. Be sure to use the updated global
bitmap for making the needed allocations.
Traditionally the backup boot sector is not set by ntfsresize because
the exact partition size is not yet known. A chkdsk is triggered to
subsequently insert it.
However ntfsresize is frequently activated by a partition editor which
has an exact knowledge of the wanted layout, and the backup boot sector
can be inserted by ntfsresize. This is only done if the target partition
size is defined with no unit suffix, and it is a multiple of the sector
size. Anyway the backup boot sector cannot overwrite useful data as it
is inserted between the file system size and the target partition size.
When the MFT is partially located beyond the end of a resized partition,
it has to be relocated after the other files have been processed
because the MFT data is needed to do the relocations. When the MFT runlist
is split over extents, all of them have to be processed.
When the beginning of the MFT is beyond the end of the resized
partition, a specific procedure has to be used to relocate this part
of the MFT and adjust the bitmap accordingly. On a test run, these
updates should not be done.
The MS_* flags originated from system constants. However the flags
passed to ntfs_mount were really unrelated to the system constants and
many new MS_* flags had to be introduced as different features were
added to the library. Those flags had no counterparts in any system
APIs, so using the same naming scheme is inappropriate.
Instead, let's namespace these flags similarly to what has already been
done in ntfsprogs/libntfs earlier. This avoids any possible conflicts
with system constants.
The values of the flags themselves are kept the same as earlier, so
backward compatibility is retained.
When the lower bound of an ntfs partition is moved down this patch
recreated new metadata in the expanded space without copying the
actual data. The existing code for moving the upper bound of the
partition has been kept unchanged.
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.
libntfs (unlike libntfs-3g) sets the volume dirty bit automatically on ntfs_mount (if not already set) and also automatically clears the volume dirty bit on ntfs_umount (if it was not already set before mount). The 'WasDirty' flag is set to indicate that the volume was already dirty when it was mounted, so setting it means bypassing the 'clear dirty flag' behaviour on unmount (it does not mean 'set dirty flag on unmount').
NVolSetWasDirty is accordingly replaced with the actions that were intended:
- If the intention was to leave the dirty bit set on unmount, we explicitly set the bit if it is not already set.
- If the intention was to simply update the 'WasDirty' bit to be consistent with earlier changes, we just comment out the statement.
This is not a perfect conversion. The VOLUME_IS_DIRTY flag reflects the _current_ state of the volume dirty bit and not the mount-time state.
However, since libntfs-3g (as opposed to libntfs) does not automatically change the dirty bit on mount and unmount (only when ntfs_volume_write_flags is called explicitly), and these tests are done directly after a mount (ntfsclone.c, ntfscp.c, ntfsresize.c, ntfswipe.c, utils.c) or when the volume is in an appropriate state (ntfsfix.c), the result will be the same.
In fact, this is how libntfs-3g operates normally, so the MS_NOATIME flag is not needed. However, other utilities might incorrectly assume that the library updates access times for them.
Investigating whether access time needs to be manually updated in other utilities is TODO.
Jean-Pierre André
Jean-Pierre André
Erik Larsson