Hello,
there was a discussion about Shadowfs' write support on IRC (#hurd @
openprojects.net) and Marcus suggested to post the conclusions - so
here they are.
The first question was: If shadowfs supports having an explicitely
specified writable filesystem[0], shadowfs might has to create whole
directory hierarchies - how can this be done? (Or should it be done at
all?.)
Example: settrans /shadow /hurd/shadowfs --writable /a /b
(which explicitely specifies /a as the only writable filesystem).
Now, /b contains '/foo/bar' and /shadow/foo/bar/baz should be created
- 'baz' would need to be somehow created as /a/foo/bar/baz. But /a is
empty, so '/foo/bar' would have to be created on /a, first.
There are several problems with this approach:
0) a filesystem shouldn't do such operations (like creating
directories), the user should. So there would be problems with the
new permissions.
1) it would mean that in every looked up virtual directory node in
shadowfs, the according path would have to be stored. This is not
nice. (An alternative to storing the path in every node would be to
automatically create the directories on the writable filesystem as
they are successfully looked up. Then the creation of whole
directory hierarchies wouldn't be needed.)
The good solution is to simply remove the option of setting a writable
filesystem explecitely and rather try to create the file on the first
writable filesystem, which contains the directory. Then, in the above
example 'baz' would be created on /b as '/b/foo/bar/baz', because /b
contains '/foo/bar'.
A live file system (e.g. for a CDROM) could then be implemented by
first mirroring the complete directory hiearchy of the CD onto a
writable filesystem and then mentioning that filesystem before the CD
when setting up shadowfs.
=> settrans /writable-cd /hurd/shadowfs /writable-filesystem /cd
There was also another question: Could dir_mkdir() be implemented by
shadowfs? The answer is: no.
This case of creating directories is comparable with looking up
files. In the latter case, dir_lookup() provides a retry port to the
user (to the real directory containg the file) and a retry name (the
file name). The user then does a lookup on the retry port with the
retry name and gets a port to the real file.
Such a retry mechanism would also be needed for dir_mkdir(). The user
should get a retry port to the real directory in which the user wants
to create the directory and should repeat the dir_mkdir() call on that
port.
Any comments?
I probably forgot something.
[0] 'writable filesystem' here means: the filesystem, where newly
created files in shadowfs should actually be stored.
moritz
--
Moritz Schulte <[EMAIL PROTECTED]> http://www.chaosdorf.de/moritz/
Debian/GNU supporter - http://www.debian.org/ http://www.gnu.org/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
