From: Noveck, Dave (dave.noveck@netapp.com)
Date: 05/20/99-02:40:06 PM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA033035DD@TAHOE.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: Caching Redeparture (was Re: File handles and hard links)
Date: Thu, 20 May 1999 12:40:06 -0700
>
> > In UNIX file systems we have the inode serial number to distiguish
> > objects which have the same name at different times (mkdir a;
> > rmdir a; mkdir a). Is there anything discriminating in your FH?
>
> The create time of the file is the only thing that can be used in this
> manner. The File ID is not there for FAT filesystems.
What's the granularity of the create time. Is it sufficient to assure
uniqueness?
>
> >
> > If the NFSv4 file attributes included some sort of identity
> > (fsid/fileid, cache cookie, whatever), would HCL be able
> > to implement it in these hard-link cases? Would it even matter?
> >
>
> It is possible but I would like to ask others if any NFS server
> implements an in memory database which stores EVERY single file which
> the NFS server serves?
I'm not sure where the memory database is coming in here.
First of all, is it the case that you have hard links? I thought NT
didn't have them. (I'll stack up my ignorance of NT against anybody's).
If there are no hard links, then you can't have the problem of two
names for a file at least at any given instant. You may have a
problem that arises after a rename with an old filename-style handle
that hasn't been updated but I'd like to understand the at-an-instant
constraints first.
I was kind of hoping that any filesystem that supported hard links would
have to give users the abiltiy to determine whether two filenames
denoted the same object. The simplest (and best for our purposes)
way of doing that is to allow you to determine a fileid associated
with each name and compare them.
So, is there anybody out there with a filesystem that has both of the
following characteristics:
a) Supports hard links
b) Has no accessible unique per-fileid. In this context, unique
means unique at a given instant. Unique-for-all-time would be
nice but I'm not counting on that.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:06 AM Z CST