This is done to match the type of the LSN struct members in layout.h.
The effect of this change is that while these members were declared with
the le64 type previously, leLSN resolves to sle64. I.e. what was
previously unsigned fields are now signed.
Following this change we also need to switch over a few macros from
unsigned to signed versions in the code that uses these struct
definitions.
Strict checking of endian-specific types mean that types that have a
fixed endianness in the data representation of the value are now defined
as complex types, enabling the compiler to catch mixed usage of these
types with native-endian types. This allows us to catch most issues
relating to usage on big-endian systems since we cannot anymore assign a
fixed-endian value to a native-endian variable and vice-versa without a
compiler error.
The downside is that we aren't able to apply simple binary operators to
the fixed-endian types anymore since they are complex... so all
combining fixed-endian constants and values with |, &, etc. and
comparison with ==, !=, <=, etc. must be replaced with a macro which
unpacks the wrapped value and performs the operation. Lots of changes,
lots of work but in the interest of good code quality it's justified.
There were multiple cases of little-endian fields being used as
CPU-endian without byte swapping. This would result in incorrect
behaviour on big-endian systems.
On big-endian systems the result of the '!=' operation would be
endian-swapped rather than the first argument (which must have been the
intended action).
This is harmless except when we do strict endianness checking, in which
case this results in a compile error. Fixed by converting values to
CPU endianness before comparing them.
In 'dump_resident_attr_val', 'i' was sometimes used as a native-endian
'int'-precision string length value and sometimes used as a little-
endian 16-bit flags value. This type of mixed usage is bad practice and
results in a hard error when strict endianness checking is used.
Fixed by introducing new variable 'flags' to hold the little-endian 16-
bit flags value.
If the attribute type is specified by the user, 'attr_type' was assigned
a CPU-endian value, however if the attribute type was not specified it
would be assigned the attribute type AT_DATA, which is a little-endian
value. The rest of the code seems to assume that 'attr_type' is
CPU-endian, so this is clearly a bug.
Resolved by fixing the endianness of the variable at little-endian,
converting the input value to little-endian when specified.
In 'dump_attr_record' the variable 'u' was first used to store a
CPU-endian 32-bit value, and then to store a 16-bit little-endian value.
This is bad practice and results in a hard error when strict endian type
checking is used.
Fixed by storing the 16-bit little-endian flags value in a new variable
'flags'.
This commit addresses issues where little-endian variables are emitted
raw to a log or output stream which is to be interpreted by the user.
Outputting data in non-native endianness can cause confusion for anybody
attempting to debug issues with a file system.
If start buffer is more recent than restart, we update committed LSN
with last record LSN of block (last_end_lsn) while applying action but
forget about it while printing records with -f for investigation
purpose.
Note that while applying actions we use start_buffer to calculate
latest page out of block 2 and block 3 and then from latest take
committed LSN. For -f we don't need buffers so we just compare
directly with committed LSN from restart.
(contributed by Rakesh Pandit)
The new compression formats used by Windows 10 uses reparse data, and
a new reparse tag which it is useful to define even though these formats
is not yet supported by ntfs-3g.
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 block 2 or block 3 points backward to block 4, it is not clear
whether the log file only consists of block 2 or block 3 or the log
file has just wrapped around. The latter is now assumed.
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.
ntfsrecover applies to the metadata the updates which were requested on
Windows but could not be completed because they were interrupted by
some event such as a power failure, a hardware crash, a software crash
or the device being unplugged. Doing so, the file system is restored
to the latest consistent state.
No update to libntfs-3g is required by this implementation.
When used with the "no-action" option, the test for self-located MFT
still reported the partition to have been repaired. Adapt the report to
only tell repairing is possible.
In an NTFS boot sector, the first sector of the partition is limited to
32 bits and it may overflow on large disks. This field is only used for
booting on the partition and it is ignored by ntfs-3g, but the warning
in mkntfs mislead users, so improve it.
Unused entries in the MFT may have a bad length leading to fetch fixups
from unallocated memory. Check the condition, but do not wipe, leave it
to chkdsk to decide what should be fixed.
When the unmounting of the partition fails after running ntfsfix, a
second try was attempted. This cannot be done and leads to more errors
because some essential records have been freed, so better quit without
making a second try.
When the new option --unused-fast is used, clusters which appear as wiped
are not written again. This is useful for avoiding virtual partitions to
be extended to their full size.
Contributed by michael
ntfsfallocate is the equivalent of fallocate(1) :
Usage : ntfsfallocate [-n] [-p] [-o offset] -l length filename
For now, it is only released as a quarantined ntfsprogs because it can
produce configurations which cause subsequent updates of the file by
Windows to hang.
Distributions have complained about releasing a non-functional ntfsck.
Actually, ntfsck and a few other developer-oriented utilities were not
meant to be released by distributions and are only compiled in if the
configure option --enable-extra is set, and, for some reason, this
option is set by most distributions.
In order to get distributions to not complain, though making the source
code available for candidate developers to improve it, the non functional
or developer-oriented utilities (ntfsck, ntfsdump_logfile, ntfsmftalloc
and ntfsmove) are now only compiled in if the configure option
--enable-quarantined is set.
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).
The ioctl() function is not implemented in the Windows variant. By forcing
a negative apparent return, an alternative is triggered to get the
partition size which is normally obtained from an ioctl().
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.
X509 certificates have a purpose field restricting what the certificate
can be used for, and EFS encryption is such a purpose. Allow EFS encryption
to be at any position in the list.
When ntfsclone'ing to a file, the target file was truncated to the volume
size. This is not useful on file systems which support sparse files. In
the case of ntfs-3g this leads to prevent optimizations specific to
appending data. So when a sparse output file is detected, it is emptied
to benefit from subsequent appending of data.
Erik Larsson
Jean-Pierre André