Windows places filenames with a trailing dot or space in the Win32
namespace and allows setting DOS names on such files. This is true even
though on Windows such filenames can only be created and accessed using
WinNT-style paths and will confuse most Windows software. Regardless,
because libntfs-3g did not allow setting DOS names on such files, in
some cases it was impossible to correctly restore, using libntfs-3g, a
directory structure that was created under Windows.
Update ntfs_set_ntfs_dos_name() to permit operating on a file that has a
long name with a trailing dot or space. But continue to forbid creating
such names on a filesystem FUSE-mounted with the windows_name option.
Additionally, continue to forbid a trailing a dot or space in DOS names;
this matches the Windows behavior.
(contributed by Eric Biggers)
The validation contained an off-by-one error. The
expression '(u32)(usa_ofs + (usa_count * 2)) > size' used 'usa_count'
after it had been decremented to skip the update sequence number entry.
Consequently, the code could read out of bounds, up to two bytes past the
end of the MST-protected record.
Furthermore, as documented in the comment in layout.h for "NTFS_RECORD"
and also on MSDN for "MULTI_SECTOR_HEADER", the update sequence array
must end before the last le16 in the first logical sector --- not merely
before the end of the record.
Fix the validation and move it into a helper function, as it was done
identically in the read and write paths.
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
- Update documentation for COLLATION_RULES
- Document how ntfs_names_full_collate() compares names
- Update comments and DEBUG code to reflect that ntfs_names_full_collate()
always access 'upcase', even in CASE_SENSITIVE mode
- Remove unneeded assignments to 'c1' and 'c2' in IGNORE_CASE mode
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
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.
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.
On-disk struct definitions used native types (u16/u32/u64/s16/s32/s64),
which doesn't say anything about the intended interpretation of the
data. The intention of having little-endian-specific types and
big-endian-specific types must have been to clarify interpretation of
data and intentions in the code. Therefore it seems reasonable to use
these types in struct definitions to clarify what data represention is
used to encode field data.
Because some struct members in layout.h are big-endian, this change also
means moving the duplicated definitions for big-endian byteswapping
macros and big-endian types found in acls.h and security.h to the
appropriate locations in endians.h and types.h respectively in order to
make them available for the struct definitions in layout.h.
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.
Replace the obsolete definition of reparse tags in layout.h by the
current definitions from msdn, and use them in reparse.c instead of
redefining them.