Panic on empty volume name

[leofidus]

PS C:\Users\redacted\source\ntfs> .\target\debug\examples\ntfs_shell.exe \\.\C:
**********************************************************************
ntfs-shell - Demonstration of the ntfs Rust crate
by Colin Finck <colin@reactos.org>
**********************************************************************

Opened "\\.\C:" read-only.

ntfs-shell:\> fsinfo
Cluster Size:       4096
File Record Size:   1024
MFT Byte Position:  0xc0000000
NTFS Version:       3.1
Sector Size:        512
Serial Number:      1651328304054153915
Size:               943060998656
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src\structured_values\volume_name.rs:96:46
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

As you can see, I indeed don't have a name set, which is just fine with Windows (Tested on Windows 10 21H1):

On a different drive with a configured name the command succeeds.

[ColinFinck]

Thanks a lot for your report and the additional comment in #10 (comment)!
I finally realized that these were actually two bugs:

• NtfsVolumeName must support empty strings as volume names. I previously only encountered filesystems that removed the entire $VOLUME_NAME attribute when the volume name was cleared. But apparently, this is not guaranteed.
• data_position must also return a position when stream_position equals the value length. This happens when we seek to the very end of a value, but also when the value is zero-sized.

Both bugs have been fixed in 61d13c6 and a063e4a.

Note that $VOLUME_NAME is always a resident attribute. The Data Runs concept only applies to non-resident attributes, hence this bug needs to be clearly separated from #10.

[leofidus]

I can confirm that it works now. After your commits I get an empty string as volume name, as expected. Thanks.