pub enum FileIdentifier {
FileId(u64),
ObjectId(u128),
ExtendedFileId([u8; 16]),
}Expand description
Which kind of identifier names the object to open.
Win32 spells this as a tagged union whose tag and payload must be kept in step by hand; here the tag is implied by the variant, so the two cannot disagree.
All three forms are supported. Only FileId appears in the
audited consumers, but an entry that could express one of its own call’s
three identifier kinds would be a narrowed OpenFileById.
§Example
The tag is implied by the variant, so it cannot disagree with the payload the way the raw union permits:
use windows_namespace_request_sys::open_by_id::FileIdentifier;
use windows_sys::Win32::Storage::FileSystem::{
ExtendedFileIdType, FileIdType, ObjectIdType,
};
assert_eq!(FileIdentifier::FileId(7).id_type(), FileIdType);
assert_eq!(FileIdentifier::ObjectId(0x1234).id_type(), ObjectIdType);
assert_eq!(FileIdentifier::ExtendedFileId([0; 16]).id_type(), ExtendedFileIdType);Variants§
FileId(u64)
A 64-bit file reference number, as reported by FileIdInfo’s
predecessor and by BY_HANDLE_FILE_INFORMATION. This is the form every
audited consumer uses.
ObjectId(u128)
A volume-scoped object identifier.
Taken as a u128 rather than a GUID deliberately. Win32’s GUID is a
dependency’s type that implements neither equality nor Debug, and a
public surface should not be shaped by whichever binding crate this
happens to build against. The conversion to GUID happens at the FFI
boundary, where it belongs.
The value is the GUID read as one big-endian number in the order of
its canonical text form: 7383249c-cb6e-11f1-857d-7ced8d529076 is
0x7383_249c_cb6e_11f1_857d_7ced_8d52_9076. That is GUID::from_u128’s
reading, and is not the order of the 16 bytes Windows stores, whose first
three fields are little-endian.
ExtendedFileId([u8; 16])
A 128-bit file reference number, as reported by FileIdInfo on ReFS,
where 64 bits is not enough to name a file.
FileIdInfo::file_id is that value.