Hi,
Is there a way to uniquely id a file from the windows file system
without matching full path?
Thanks,
Lior
Of course there is. Insert a unique ID somewhere in the files data.
----- Original Message -----
From: “Lior Sion”
To: “File Systems Developers”
Sent: Monday, April 21, 2003 5:11 PM
Subject: [ntfsd] uniquely id a file
Hi,
Is there a way to uniquely id a file from the windows file system
without matching full path?
Thanks,
Lior
—
You are currently subscribed to ntfsd as: xxxxx@linkwave.org
To unsubscribe send a blank email to xxxxx@lists.osr.com
On NTFS - yes.
On FAT - yes, but the defragmenter will invalidate these IDs.
Max
----- Original Message -----
From: Lior Sion
To: File Systems Developers
Sent: Monday, April 21, 2003 7:11 PM
Subject: [ntfsd] uniquely id a file
Hi,
Is there a way to uniquely id a file from the windows file system without matching full path?
Thanks,
Lior
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Although rare, you also have to be careful about file “instance”, since
a file ID can be re-used after the previous owner has been deleted.
/TomH
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, April 21, 2003 2:24 PM
To: File Systems Developers
Subject: [ntfsd] Re: uniquely id a file
On NTFS - yes.
On FAT - yes, but the defragmenter will invalidate these IDs.
Max
----- Original Message -----
From: Lior Sion mailto:xxxxx
To: File Systems Developers mailto:xxxxx
Sent: Monday, April 21, 2003 7:11 PM
Subject: [ntfsd] uniquely id a file
Hi,
Is there a way to uniquely id a file from the windows file
system without matching full path?
Thanks,
Lior
—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com mailto:xxxxx
—
You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Really? The MFT index can be resued. I thought the id was a combination of
the MFT index and an instance counter.
It is. However, the instance counter isn’t large enough to guarantee
that a file id will never be reused. Personally, I don’t like to count
on anything that that isn’t “guaranteed”, so I add in the object create
time to be 100% sure that my file id plus create time is unique.
-----Original Message-----
From: Lyndon J. Clarke [mailto:xxxxx@gcplc.com]
Sent: Wednesday, April 30, 2003 10:41 AM
To: File Systems Developers
Subject: [ntfsd] Re: uniquely id a file
Really? The MFT index can be resued. I thought the id was a combination
of
the MFT index and an instance counter.
You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I thought the instance counter was 16 bits. I thought that when its exhasu
sted the Mft index couldnt be reused. Is it wrong? I wonder about the
timestamp when time is adjusted due to ntp or something like that.
I never heard that an MFT index could not be reused when the instance
counter wrapped. I am going to have to think about this one. This is
the description of the file ID from file system developer documentation.
It indicates that file id’s are not guaranteed to be unique across time.
Perhaps NTFS makes some guarantee above and beyond this that I am not
aware of.
“File reference numbers, also called file IDs, are guaranteed to be
unique only within a static file system. They are not guaranteed to be
unique over time, because file systems are free to reuse them. Nor are
they guaranteed to remain constant.”
As for using the create time of the file, I don’t think time adjustment
is much of an issue. The odds of a file with a file ID that is unique
at a point in time coupled with a 64-bit create time of a file having a
collision is so minute. I would never use a create time without the
file ID, but both together is just insurance. But if it is true that
the file ID is guaranteed to be unique - even over long periods of time
- then this insurance is unnecessary.
If anyone know for certain that file id’s can never be re-used - that
would be good information to know. Of course we are talking NTFS here -
we all know that file id’s are completely unusable for uniqueness on
FAT.
/TomH
-----Original Message-----
From: Lyndon J. Clarke [mailto:xxxxx@gcplc.com]
Sent: Thursday, May 01, 2003 6:01 AM
To: File Systems Developers
Subject: [ntfsd] Re: uniquely id a file
I thought the instance counter was 16 bits. I thought that when its
exhasu
sted the Mft index couldnt be reused. Is it wrong? I wonder about the
timestamp when time is adjusted due to ntp or something like that.
You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
In an old driver I worked on a few years ago, we needed a unique ID
across all volumes on the system. What I did was create a 64 bit ID
number based on two components: 1) A 32-bit CRC of the uppercased path
and file name (drive letter not includes) and 2) A 32-bit CRC of the
uppercased volume device name (\device\harddisk%d.…). I then combined
these two 32-bit CRC values to create a 64-bit ID.
This was not by architecture; I had to make a quick fix to someone
else’s code where they were using the file ID from the FSD.
FYI: File IDs from the FSD are not unique between streams on NTFS, this
is why I created the bastard code I just described.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tom Hansen
Sent: Thursday, May 01, 2003 6:23 AM
To: File Systems Developers
Subject: [ntfsd] Re: uniquely id a file
I never heard that an MFT index could not be reused when the instance
counter wrapped. I am going to have to think about this one. This is
the description of the file ID from file system developer documentation.
It indicates that file id’s are not guaranteed to be unique across time.
Perhaps NTFS makes some guarantee above and beyond this that I am not
aware of.
“File reference numbers, also called file IDs, are guaranteed to be
unique only within a static file system. They are not guaranteed to be
unique over time, because file systems are free to reuse them. Nor are
they guaranteed to remain constant.”
As for using the create time of the file, I don’t think time adjustment
is much of an issue. The odds of a file with a file ID that is unique
at a point in time coupled with a 64-bit create time of a file having a
collision is so minute. I would never use a create time without the
file ID, but both together is just insurance. But if it is true that
the file ID is guaranteed to be unique - even over long periods of time
- then this insurance is unnecessary.
If anyone know for certain that file id’s can never be re-used - that
would be good information to know. Of course we are talking NTFS here -
we all know that file id’s are completely unusable for uniqueness on
FAT.
/TomH
-----Original Message-----
From: Lyndon J. Clarke [mailto:xxxxx@gcplc.com]
Sent: Thursday, May 01, 2003 6:01 AM
To: File Systems Developers
Subject: [ntfsd] Re: uniquely id a file
I thought the instance counter was 16 bits. I thought that when its
exhasu
sted the Mft index couldnt be reused. Is it wrong? I wonder about the
timestamp when time is adjusted due to ntp or something like that.
You are currently subscribed to ntfsd as: xxxxx@inflectionsystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This is incorrect. The 16 bit instance counter simply wraps and the MFT
index will continue to be used.
Neal Christiansen
Microsoft File System Filter Group
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Lyndon J. Clarke [mailto:xxxxx@gcplc.com]
Sent: Thursday, May 01, 2003 3:01 AM
To: File Systems Developers
Subject: [ntfsd] Re: uniquely id a file
I thought the instance counter was 16 bits. I thought that when its
exhasu
sted the Mft index couldnt be reused. Is it wrong? I wonder about the
timestamp when time is adjusted due to ntp or something like that.
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com