[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: shadowfs



On Fri, May 12, 2000 at 10:53:26AM +0300, Kalle Olavi Niemitalo wrote:
> Tomasz Wegrzanowski <maniek@beer.com> 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.

Why to fork shadowfs ?
Why not operating it as single thread or 1 thr/per call ?

> 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?

Ehm, is there any need for *entering* directories ?
I thought there is no such thing anywhere but in UI.
    ( autonmounter reacts for ls, so it doesn't need any
      special support for enter_directory )

We can simply merge listings ( any cache ?, invalidated at dir_notice_changes ??? )
and find'n'forward everything else.



Reply to: