The computing of replacement bytes for overwriting undeletable files
uses random values and standard ones instead of the values provided in
option --bytes. Fix the mixup between both logics, mention the difference
in the documentation and reject defining both options --bytes and --undel.
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 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
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).
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.
'wipe_mft' didn't write any $MFTMirr entries for newly manufactured
entries (i.e. entries that were unused and therefore competely wiped and
replaced with a newly initialized copy).
The dereferencing of 'offset' and 'usa' from the MFT record wasn't an
le16* dereference but a u8* dereference, leading to only the least
significant byte (little-endian systems) or the most significant byte
(big-endian systems) being part of the value. (So while this bug could
go unnoticed on little-endian systems for volumes with small values of
'usa', it caused even more significant problems on big-endian systems.)
Fixed by properly casting the address to le16* before dereferencing.
'wipe_mft' was hardcoded to use the USA size of a 1024 byte MFT record
when creating new blank MFT entries. It now calculates the USA size
based on vol->mft_record_size.
Note: The NTFS_MNT_FORCE, in addition to what MS_RECOVER does, also bypasses the check for the 'dirty' bit in libntfs' ntfs_mount.
However, this check does not exist in libntfs-3g (libntfs-3g will not check or change the dirty bit, being confident that it can handle volumes marked as 'dirty'), so in essence the same behaviour is achieved with MS_RECOVER.
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.
ntfs_rl_pwrite has an additional parameter, ofs, in libntfs-3g. Setting ofs to 0 seems to imply the same behaviour as expected from the libntfs equivalent.
volume.[hc]::ntfs_libntfs_version() which returns a pointer to a
static const string of the libntfs verion, i.e. at the moment this is
"8.0.0". This required moving the version specifications from
libntfs/Makefile.am to configure.ac. This should hopefully have the
sideeffect that I will remember to increment it when incrementing the
ntfsprogs version number when making a release given the two are
right under one another. (Anton)
- Change ALL utilities to display the libntfs version they are running
on. This should make debugging easier in the case that people are
running mismatched utilities/library. (Anton)
