Seeing a mention of file iDs brought an old question to my mind: just how
much does NT/Win2K (or, for that matter, other systems such as Unix) require
them, at the user interface? A quick look only uncovered
GetFileInformationByHandle as providing them to the application, and the
only suggested use was to detect whether two handles referred to the same
file.
I understand why the structure underlying the file ID can be useful when
multiple directory entries refer to the same file (using hard rather than
soft links), but in the typical case where only a single directory entry
exists and no ‘object ID’ (GUID?) has been defined is there any need for a
permanent, or even a semi-permanent, FID if the single directory entry has
some other way to target the file? I could even imagine generating a FID on
the fly if GetFileInformationByHandle were called, though if Win32 provided
for passing a null value if no FID existed that might be more convenient
(how does it deal with FAT files, especially if truncated to null and then
repopulated?).
Thanks for any insights,
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
It is useful for applications to be able to use a file id
along with a volume id of some kind to uniquely identify
the file. Therefore, something should be provided.
One useful thing you could provide would be the LCN of
the first block in the file or the logical block number
of the file header if one exists.
Just my opinion, Rick Cadruvi…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Bill Todd
Sent: Wednesday, February 21, 2001 9:08 PM
To: File Systems Developers
Subject: [ntfsd] File IDs
Seeing a mention of file iDs brought an old question to my mind: just how
much does NT/Win2K (or, for that matter, other systems such as Unix) require
them, at the user interface? A quick look only uncovered
GetFileInformationByHandle as providing them to the application, and the
only suggested use was to detect whether two handles referred to the same
file.
I understand why the structure underlying the file ID can be useful when
multiple directory entries refer to the same file (using hard rather than
soft links), but in the typical case where only a single directory entry
exists and no ‘object ID’ (GUID?) has been defined is there any need for a
permanent, or even a semi-permanent, FID if the single directory entry has
some other way to target the file? I could even imagine generating a FID on
the fly if GetFileInformationByHandle were called, though if Win32 provided
for passing a null value if no FID existed that might be more convenient
(how does it deal with FAT files, especially if truncated to null and then
repopulated?).
Thanks for any insights,
You are currently subscribed to ntfsd as: xxxxx@rdperf.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
----- Original Message -----
From: Rick Cadruvi
To: File Systems Developers
Sent: Friday, February 23, 2001 11:52 AM
Subject: [ntfsd] RE: File IDs
> It is useful for applications to be able to use a file id
> along with a volume id of some kind to uniquely identify
> the file. Therefore, something should be provided.
My point was that in some on-disk-structure file system architectures a very
large percentage of the time providing a stable file ID entails work to
create something that is never used by an application, hence the question of
whether generating one on demand (e.g., only when GetFileInformationByHandle
was called, if that’s the only mechanism for transmitting a FID to an
application, or when other considerations such as multiple links made a FID
desirable) was a reasonable alternative.
- bill
>
> One useful thing you could provide would be the LCN of
> the first block in the file or the logical block number
> of the file header if one exists.
>
>
> Just my opinion, Rick Cadruvi…
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Bill Todd
> > Sent: Wednesday, February 21, 2001 9:08 PM
> > To: File Systems Developers
> > Subject: [ntfsd] File IDs
> >
> >
> > Seeing a mention of file iDs brought an old question to my mind: just
how
> > much does NT/Win2K (or, for that matter, other systems such as Unix)
require
> > them, at the user interface? A quick look only uncovered
> > GetFileInformationByHandle as providing them to the application, and the
> > only suggested use was to detect whether two handles referred to the
same
> > file.
> >
> > I understand why the structure underlying the file ID can be useful when
> > multiple directory entries refer to the same file (using hard rather
than
> > soft links), but in the typical case where only a single directory entry
> > exists and no ‘object ID’ (GUID?) has been defined is there any need for
a
> > permanent, or even a semi-permanent, FID if the single directory entry
has
> > some other way to target the file? I could even imagine generating a
FID on
> > the fly if GetFileInformationByHandle were called, though if Win32
provided
> > for passing a null value if no FID existed that might be more convenient
> > (how does it deal with FAT files, especially if truncated to null and
then
> > repopulated?).
> >
> > Thanks for any insights,
> >
> > - bill
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@rdperf.com
> > To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
> —
> You are currently subscribed to ntfsd as: xxxxx@foo.mv.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
My opinion is that as long as 2 seperate applicaitons
running in seperate process context can get a FID
that will be the same and uniquely identifies this file
for as long as it remains open (better yet for the life
of the file), what that FID is or how it is generated is
irrelevant. Generating one on the fly should be fine.
Why is one needed?
Lets say I want to write a database application that
needs to do some form of caching on it’s own or maybe it’s
own specialized data locking mechanism. It would
be necessary to have a way to know that 2 seperate processes
(or even just 2 sepearate threads) are dealing with the same
file. To do that you need something like a FID or a starting
LCN or something. Since getting the starting LCN isn’t supported
on non-WinNT systems by Win32, the programmer needs a FID.
I have NO idea what FAT returns, but it does return something
and it appears to be unique and consistent.
just my opinion,
Rick Cadruvi…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Bill Todd
Sent: Friday, February 23, 2001 9:51 AM
To: File Systems Developers
Subject: [ntfsd] RE: File IDs
----- Original Message -----
From: Rick Cadruvi
> To: File Systems Developers
> Sent: Friday, February 23, 2001 11:52 AM
> Subject: [ntfsd] RE: File IDs
>
>
> > It is useful for applications to be able to use a file id
> > along with a volume id of some kind to uniquely identify
> > the file. Therefore, something should be provided.
>
> My point was that in some on-disk-structure file system architectures a very
> large percentage of the time providing a stable file ID entails work to
> create something that is never used by an application, hence the question of
> whether generating one on demand (e.g., only when GetFileInformationByHandle
> was called, if that’s the only mechanism for transmitting a FID to an
> application, or when other considerations such as multiple links made a FID
> desirable) was a reasonable alternative.
>
> - bill
>
> >
> > One useful thing you could provide would be the LCN of
> > the first block in the file or the logical block number
> > of the file header if one exists.
> >
> >
> > Just my opinion, Rick Cadruvi…
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of Bill Todd
> > > Sent: Wednesday, February 21, 2001 9:08 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] File IDs
> > >
> > >
> > > Seeing a mention of file iDs brought an old question to my mind: just
> how
> > > much does NT/Win2K (or, for that matter, other systems such as Unix)
> require
> > > them, at the user interface? A quick look only uncovered
> > > GetFileInformationByHandle as providing them to the application, and the
> > > only suggested use was to detect whether two handles referred to the
> same
> > > file.
> > >
> > > I understand why the structure underlying the file ID can be useful when
> > > multiple directory entries refer to the same file (using hard rather
> than
> > > soft links), but in the typical case where only a single directory entry
> > > exists and no ‘object ID’ (GUID?) has been defined is there any need for
> a
> > > permanent, or even a semi-permanent, FID if the single directory entry
> has
> > > some other way to target the file? I could even imagine generating a
> FID on
> > > the fly if GetFileInformationByHandle were called, though if Win32
> provided
> > > for passing a null value if no FID existed that might be more convenient
> > > (how does it deal with FAT files, especially if truncated to null and
> then
> > > repopulated?).
> > >
> > > Thanks for any insights,
> > >
> > > - bill
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@rdperf.com
> > > To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@foo.mv.com
> > To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdperf.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Rick,
I’d just like to point out that while some kind of file ID has its uses, the start cluster doesn’t. Defragging the file can move the clusters around, even while it is open. I had trouble with my cache handling in this area!
Andy
Get your free email from AltaVista at http://altavista.iname.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
I know FastFat’s File ID may not survive a defrag, but what about NTFS? How
are its IDs generated?
-----Original Message-----
From: xxxxx@earthling.net [mailto:xxxxx@earthling.net]
Sent: Monday, February 26, 2001 4:17 AM
To: File Systems Developers
Cc: xxxxx@lists.osr.com
Subject: [ntfsd] RE: File IDs
Rick,
I’d just like to point out that while some kind of file ID has its uses, the
start cluster doesn’t. Defragging the file can move the clusters around,
even while it is open. I had trouble with my cache handling in this area!
Andy
Get your free email from AltaVista at http://altavista.iname.com
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
NTFS file ID’s are composed of their master file table index–aka inode
number–and a generation number. Coincidentally, this is the same mechanism
used by the UNIX file system in System V to export file ID’s to NFS. As
long as the defrag program doesn’t try to remove holes in the master file
table, the ID’s should not change.
-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Monday, February 26, 2001 9:23 AM
To: File Systems Developers
Subject: [ntfsd] RE: File IDs
I know FastFat’s File ID may not survive a defrag, but what about NTFS? How
are its IDs generated?
-----Original Message-----
From: xxxxx@earthling.net [ mailto:xxxxx@earthling.net
mailto:xxxxx ]
Sent: Monday, February 26, 2001 4:17 AM
To: File Systems Developers
Cc: xxxxx@lists.osr.com
Subject: [ntfsd] RE: File IDs
Rick,
I’d just like to point out that while some kind of file ID has its uses, the
start cluster doesn’t. Defragging the file can move the clusters around,
even while it is open. I had trouble with my cache handling in this area!
Andy
----------------------------------------------------------------
Get your free email from AltaVista at http://altavista.iname.com
http:
—
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@nsisw.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></mailto:xxxxx>
Andy,
You’re right about that. It also appears that that FSCTL_MOVE_FILE
IOCTL would allow moving a previously open and active file. It would
be intereting to know what responsibilities the degragmenter and
the application have in handling I/O interlocking in case an
application wants to update the file while a MOVE is happening.
There is also the cache implications as you point out to this.
Rick…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@earthling.net
Sent: Monday, February 26, 2001 1:17 AM
To: File Systems Developers
Cc: xxxxx@lists.osr.com
Subject: [ntfsd] RE: File IDs
Rick,
I’d just like to point out that while some kind of file ID has its uses, the start cluster doesn’t. Defragging the file
can move the clusters around, even while it is open. I had trouble with my cache handling in this area!
Andy
Get your free email from AltaVista at http://altavista.iname.com
You are currently subscribed to ntfsd as: xxxxx@rdperf.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com