| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The attribute length is relative to the attribute start, not to the data runs start!
This 64 byte difference previously caused a panic when data run information filled the entire File Record, and `end` was outside the File Record boundaries.
|
|
It previously returned the length reported by the current data run.
This is correct for the first data run, but breaks when the reader moved to a subsequent one.
Which is why we now save the length passed to us at creation time.
|
|
|
|
For `following_entries` to work, its length must always be one less than `inner_iterators` length.
This broke when I started filtering out the last entry without any information.
Now `following_entries` is always incremented together with `inner_iterators`.
`None` is used to indicate a last entry without any information.
Minimum example where this broke:
* Top-level node (0) has a subnode (1) and is not the last entry (= inserts an entry into `following_entries`).
* Subnode (1) has a subnode (2) and is the last entry.
* Subnode (2) has no subnode and is the last entry.
When subnode (2) finished iterating, its iterator is dropped and the iterator of subnode (1) becomes the last one.
The next item in `following_entries` must now be `None` to loop one more time.
Now we notice that subnode (1) has also been fully iterated, drop its iterator, and let the iterator of top-level node (0) become the last iterator.
The entry in `following_entries` is now picked up, associated to the correct iterator (0), and returned.
|
|
This crate must never panic on invalid input data!
|
|
Turns out that we won't use this enum for anything else than attribute values, and `Slice` always corresponds to a resident attribute value, so reflect that in the naming.
Index keys still use slices without this enum.
|
|
An NTFS file often has more than one FileName attribute and the caller is likely interested in a specific one.
ntfs-shell is changed accordingly to prefer the long filenames.
|
|
This makes `NtfsFile::directory_index` and `NtfsFile::name` work even if the attributes they are looking for are part of an Attribute List.
We keep a fast path for the few attribute types that are always resident.
|
|
`NtfsAttributeListNonResidentAttributeValue`.
This enables us to read a data value spread over multiple data runs of multiple connected attributes just like a single contiguous value.
A caller can read an attribute value the same way, no matter if it's internally stored as a resident attribute, non-resident attribute, or non-resident attribute within an AttributeList.
|
|
This one can be resident or non-resident, hence this commit also adds some related support code.
|
|
|
|
There is no difference between an empty attribute name and no attribute name at all.
|
|
This change has notable negative performance implications, as the $MFT record is now read and fixed up on every file lookup.
This needs to be fixed later via caching.
|
|
|
|
This enables to decide whether a $FILE_NAME Index Entry is a regular file or a directory without loading the FILE Record and looking up the $STANDARD_INFORMATION attribute for that entry first.
|
|
|
|
|
|
Add a test that would have caught this.
|
|
|
|
|
|
Testing shows that there are NTFS filesystems that have a last index entry *without* a subnode (i.e. with no useful information at all).
|
|
|
|
|
|
|
|
This greatly reduces the number of heap allocations when traversing an index.
|
|
This introduces parsing the $UpCase file to perform case-insensitive searches.
|
|
|
|
|
|
You can't just compare `other` with `self` when the ordering is important.
|
|
|
|
Index entry keys do not necessarily correspond to the structured values. In fact, file name indexes are the exception and not the rule. All other index types have dedicated key structures.
Likewise, some index types (e.g. SDH and SII) also have extra data structures instead of a file reference.
Finally, some other index types (like R over Reparse points) only have a key structure, but neither data nor a file reference.
|
|
This prevents naming collisions with NTFS fields called "data".
|
|
|
|
|
|
|
|
This is where things get dirty. As NTFS requires us to fix up records, we can't continue our previous design of avoiding dynamic allocations and reading everything on demand via `io::Read`.
Instead, we now read an entire record (usually not larger than 4 KiB), fix it up, and store it in a `Vec`.
This required changes almost everywhere.
It should be noted that many non-resident attributes are not part of a record, which is why structured values are now implemented differently depending on the attribute type.
On the plus side, many structures need less borrowing now, which makes them more comfortable to use.
I have also added missing sanity checks with precise errors where appropriate.
|
|
|
|
This introduces a hard dependency on alloc for a core feature.
It is required as long as we don't know the B-tree depth in advance, and need to maintain a stack with elements per layer during traversal.
|
|
We reuse the former name for something else in the next commit.
|
|
|
|
|
|
|
