Runlists with no runs are tolerated though not expected. However merging
such runlists is problematic as there is no significant vcn to examine.
So avoid merging them, and just return the other runlist.
A zero-size run is the universal way to indentify the end of a runlist,
so we must reject zero-sized runs when decompressing a runlist. A
zero-size data run is an error, and a zero-size hole is simply ignored.
When the unreadable directory has an ATTRIBUTE_LIST attribute and an
INDEX_ALLOCATION attribute occupying split over several extents, the first
of which defines a single cluster, the first INDEX_ALLOCATION extent has
lowest_vcn=0 and highest_vcn=0, and the second one has lowest_vcn=1.
This unusual case, which can be created by the combination of a small
volume and near-full MFT records, triggers some special-case behavior in
ntfs_mapping_pairs_decompress_i(). That behavior is incorrect if the
attribute's first extent only contains a single cluster, since in that case
highest_vcn=0 as well.
This configuration has been tested on Windows and it *is* able to
successfully read the directory. This supports the hypothesis that the
volume is valid and NTFS-3g has a bug on the read side.
This bug could, in theory, occur with any non-resident attribute, not just
INDEX_ALLOCATION attributes.
(Contributed by Eric Biggers)
Jean-Pierre André
Jean-Pierre André
jpandre
szaka