Norbert Nemec wrote: > > Question: Is there any detailed description of the utopious shadowfs yet? Or > is it only a vague "Would be a neat thing if we had some thing like..."? > > If there is none, the first thing to happen should be that someone puts a > *complete* description together before anyone starts coding on it. Some > things that should be added to the to-be-considered list: > > * File permissions (relatively easy) > * Directory permissions (not that easy) > * What about deletion of files? If I have a read-only base filesystem and a > read-write filesystem mounted on top of it, the result should behave just > like a ordinary read-write system. So I should be able to delete files and > directories. How should that be marked in a straight-forward way?
I'm not sure this directly answers your question, and it presumes that there isn't a spec sheet on how the shadowfs works, but I think it should operate in as single directly and behave like a bunch of symlinks. The configuration files for /sdir would say include /dirOne/*, /dirTwo/*.html, /dirTwo/*.gif, etc. You shouldn't be able to delete files, both for conformity (you can't create them either) and because I don't think you can delete what a symlink points to by going through the symlink (although I could be wrong). Anyway, I see two points of difficulty here; One is performace: having it read through every directory every time would be bad, making it cache the directories and only read them when they've changed (or more specifically when they've changed and somebody asks for a dir listing) would be much more efficient. The other problem is the configuration: where do you put the config files, how flexible should it be at picking which files are actually in the dir, stuff like that. Btw, I'm pretty sure there is some specifics out there on how it's supposed to work. I recall reading something about it of the Hurd website... > > On Fri, May 12, 2000 at 10:53:26AM +0300, Kalle Olavi Niemitalo wrote: > > Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes: > > > > > Am I very wrong > > > or readonly shadowfs > > > needs only to check, upon open request, > > > if file exist on first fs > > > if not, if on the next one, etc, > > > and if yes forward everything to good fs > > > and if not return simple error ??? > > > > If the file is actually a directory, shadowfs should open > > directories with that name in all many file systems it can, and > > set up a nested shadowfs. Symlinks to directories should be left > > as symlinks; if the shadowfs showed them as directories, its > > clients could get in infinite loops. > > > > Hmmh -- what happens if the user: > > > > - creates directories ~/1 and ~/2 and sets up sets up a shadowfs > > ~/shadow which merges them > > > > - creates a directory ~/1/dir > > > > - changes directory to ~/shadow/dir: This should give him either > > a reparented ~/1/dir or a shadowfs which forwards to it. > > > > - creates a directory ~/2/dir and then a file ~/2/dir/file > > > > - attempts to open file in the current directory (~/shadow/dir): > > Can this be made to work? The shadowfs doesn't have a port to > > ~/2/dir yet -- it would have to notice that ~/2/dir was created > > after ~/shadow/dir was opened. <hurd/fs.defs> has a routine > > dir_notice_changes; would the shadowfs have to use that? -- Rhamphoryncus [EMAIL PROTECTED] Capitalism is like nuclear war; the only way to win is not to play the game.
