Subject: RE: file_id

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 30 Nov 2002 03:31:12 -0800

I'm curious.  What do existing clients do (in terms of returning an
st_ino value) when the server does not support fileid? After all,
fileid is only a "recommended" attribute (just like mime_type :-).   

-----Original Message-----
From: Gordon Waidhofer [mailto:[email-masked]]
Sent: Thursday, November 28, 2002 12:32 AM
To: Eric Sedlar; [email-masked]
Subject: RE: file_id

The APIs (ala POSIX), especially stat(2).
The fileid is mapped to 'ino_t st_ino'.
Most systems use a 32 bit ino_t, some support 64 bit.
Some programs use st_ino for identity, like cmp(1)
and cp(1). For example, cp(1) uses st_ino to
prevent 'cp x x'. Is it important? It's sorta
a judgement call. I'd urge heroics on this one.
If taken lightly, you could encounter weird
problems in the field that are awkward to explain.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric Sedlar
Sent: Wednesday, November 27, 2002 6:29 PM
To: [email-masked]
Subject: file_id

How important is it to support file_id?  Our filesystem has a 16 byte GUID, and the file_id attribute is fixed at 8 bytes.  Is there some reason it wasn't variable length?
 
--Eric

---

From: Trond Myklebust <[email-masked]>
Date: 30 Nov 2002 17:21:55 +0100

>>>>> " " == Dave Noveck <Noveck> writes:

     > I'm curious.  What do existing clients do (in terms of
     > returning an st_ino value) when the server does not support
     > fileid? After all, fileid is only a "recommended" attribute
     > (just like mime_type :-).

Linux has a VFS function for generating unique inode numbers on the
fly. We tend to use that for filesystems that don't provide their own
fileid.

The problem with that is, of course, that if the cached file metadata
gets garbage collected, then your st_ino value will be lost (unless
you can save it as a named attribute or something clever like that).

Cheers,
  Trond