[9fans] unique identity to virtual files

[9fans] unique identity to virtual files

[Steve Simon]

The subject probably doesn't explain at all well.

I have a program (A) I have written, it can optionally run atop of a
a synthetic filesystem (B) which expands some files into directories
of files.

The A needs to be able to tell the difference between a
'real' directory and one generated by B.

I could use the muid and uid and gid as magic strings, alternatively I
could use the dev or/and type fields from stat.

Anyone have any strong feelings on the ``right'' way to do this?

-Steve

Re: [9fans] unique identity to virtual files

[erik quanstrom]

> The subject probably doesn't explain at all well.
> 
> I have a program (A) I have written, it can optionally run atop of a
> a synthetic filesystem (B) which expands some files into directories
> of files.
> 
> The A needs to be able to tell the difference between a
> 'real' directory and one generated by B.
> 
> I could use the muid and uid and gid as magic strings, alternatively I
> could use the dev or/and type fields from stat.
> 
> Anyone have any strong feelings on the ``right'' way to do this?
> 

i don't know about "strong" feelings.  but i would think that you
would want A to not have to know about which files have been
expanded.  this defeats the purpose of B, which is to hide the
details of what it does behind a fs interface.

perhaps this means that you require A to run on B.  or perhaps
you fold B into A so that it knows the details of which file is which.

if you stick to the current design, the file name might be the easiest
to modify, perhaps followed by the Qid.

- erik

Re: [9fans] unique identity to virtual files

[Russ Cox]

> I have a program (A) I have written, it can optionally run atop of a
> a synthetic filesystem (B) which expands some files into directories
> of files.
> 
> The A needs to be able to tell the difference between a
> 'real' directory and one generated by B.

the usual answer is "don't do that."  i.e. if you want to use A,
then run it on a name space where B isn't around.
you can't use the dev/type fields because devmnt will
set those to things like M 123123 over which B has
no control.  you could use the qid but exportfs
might fiddle with those.

using the uid/gid would make the most sense to me,
in that it would be the least unexpected.  for example,
since their file systems don't contain user and group info,
dossrv sets uid & gid to bill & trog, while 9660srv sets the
uid & gid (when the cd doesn't contain those)
to cdrom & iso9660/joliet/ridge etc.  it would in that
context make a little sense for your expander file system to
set the uid/gid on files it has created, and then a little less
sense for your program (A) to treat those specially.

really the right answer is to run A in a tree where B has
not been mounted, though.

russ

Re: [9fans] unique identity to virtual files

[roger peppe]

On Jan 15, 2008 2:35 PM, Russ Cox <rsc@swtch.com> wrote:
> the usual answer is "don't do that."

which i agree with, but assuming you *are* doing that:

> using the uid/gid would make the most sense to me,
> in that it would be the least unexpected.

or maybe even muid, as very little uses it, and
in some sense perhaps the synthetic filesystem
is the last thing that modified the (appearance of) the
original file. the original muid isn't necessarily lost,
as files within the synthetic directory could hold
the original.

Re: [9fans] unique identity to virtual files

[Gary Wright]

On Jan 15, 2008, at 8:09 AM, Steve Simon wrote:
> The A needs to be able to tell the difference between a
> 'real' directory and one generated by B.
>
> I could use the muid and uid and gid as magic strings, alternatively I
> could use the dev or/and type fields from stat.

Any reason why B, since it is already synthetic, can't synthesize
a special file with a well-known name that can be used to signal
the virtual expansion?  It seems simpler than overloading the
semantics of a stat entry.  You could even use the 'aname' of the
attach message to specify the name of the sigil file if you need
it to be dynamic.

Gary Wright

Re: [9fans] unique identity to virtual files

[Charles Forsyth]

> You could even use the 'aname' of the
> attach message to specify the name of the sigil file if you need
> it to be dynamic.

you could use the md5 of the name to be expanded