A Union of two directories

[Esh, Andrew]

Nice description Simo. It caused me to think.

I can see two cases for the use of such a union. The first is where the user
wants to make a foreground overlay which they can edit, where files are made
read-write by copying from the background to the foreground. This appears
the same as a normal file system until the background share is unmounted.
Then, the skeleton of the tree and the user's edited files are all that
remains. Unless such a system is used under the control of a tool such as
ClearCase, I don't see what utility it would have in the general market.
(Consider the merges, or the fact that the changes would always be separate.
Neither case is both common and simple.) Perhaps there are software
engineering applications. It would take a software engineer to operate it.
;)

The second case is where Simo's option "background write_over" is turned
off. This effectively puts the background in the foreground, and prevents
writing. The user's read-write "underlay" then occupies any file namespace
not covered by the read-only overlay. This would be useful for system
directories such as network storage areas that contain organization-wide
applications. It would be mounted on the user's "Program Files" folder, for
example. Mounting their personal applications folder in the same place would
cause their own applications to appear to be installed side-by-side with the
shared ones. Any conflict would cause the read-only system version of the
file to show through. Writing a file into the combined folders would only be
allowed if the file doesn't already exist, or if it only exists in the
personal folder. This configuration would appeal to system administrators,
who want to make sure the users have access to centrally maintained
applications, without giving the users the ability to alter the
applications.

Opposite to the above, the user may want to be able to overlay their
personal folder on the shared one. Going back to the "Program Files"
example, this would allow one user to install an updated version of an
application over an older version of the same application in the shared
folder. This configuration would be useful in supporting a super-user who
takes responsibility for maintaining their own applications, who wants to
take advantage of the default installations.

Given my assumption that "dir1" and "dir2" ("dir3"? "dir4"?) are keywords
which can be used to determine the background-to-foreground order of the
overlay, and the inclusion of the "read-only" "read-write" controls which
are already available, the latter two configurations can be accomplished.
Perhaps a better way would be to introduce a "meta-share", which names a
number of other shares, the order in which they should be overlaid, and
their write status. Other normal share keywords controlling user access
could also be applied. Here is an example of the second configuration
described above:

[accounting_apps]
	path=/storage/shared
	public = yes
	writable = no
	guest ok = yes

[john_doe_personal_apps]
	path=/storage/home/john_doe/apps
	public = no
	writable = yes
	guest ok = no
	valid users = "@CENTRAL+John Doe"
	write list = "@CENTRAL+John Doe"

[john_doe_apps]
	meta share = accounting_apps, john_doe_personal_apps
	write control = no, yes
	public = no
	valid users = "@CENTRAL+John Doe"
	write list = "@CENTRAL+John Doe"	

Note that shares named to the left in the "meta share" keyword are in the
foreground. The "write control" keyword arguments refer by order to the
shares named in the "meta share" keyword.

By changing the order of the "meta share" and the "write control" arguments,
this configuration becomes the super-user example.

In my opinion, this would be useful.

As was said earlier, this all belongs in a VFS layer.

> -----Original Message-----
> From: Simo Sorce [mailto:simo.sorce at xsec.it]
> Sent: Tuesday, February 04, 2003 4:38 AM
> To: David Lee
> Cc: Stefan (metze) Metzmacher; 'samba-technical at lists.samba.org'
> Subject: Re: A Union of two directories
> 
> 
> On Tue, 2003-02-04 at 11:03, David Lee wrote:
> > On Tue, 4 Feb 2003, Stefan (metze) Metzmacher wrote:
> > 
> > > It would be fine to have config options for match witch 
> files should be 
> > > taken from with
> > > directory.
> > > 
> > > something like this:
> > > dir1 path = /home/samba
> > > dir1 mode = readonly
> > > dir1 files = *.c,*.h,configure,Makefile
> > > dir1 exclude files = *.o
> > > dir2 path = /home/%m/samba
> > > dir2 mode = write
> > > dir2 files = *.o
> > > dir2 exclude files = *.c,*.h
> > > 
> > > and something simular for directories
> 
> I think the easiest thing is to have a "background common 
> read-only directory"
> 
> only few parameter needed:
> 
> background path = /home/common
> background write_over = yes|no
> 
> all the files present here will be seen as read-only by everyone.
> if you open the file read-write you may choose to either fail the
> open or copy over the file to the user directory and use that file
> instead.
> In this situation only files _not_ present in user directory are taken
> from the background dir, so that user created one are in "foreground".
> 
> Simo.
> 
> 
> -- 
> Simo Sorce - simo.sorce at xsec.it
> Xsec s.r.l.
> via Durando 10 Ed. G - 20158 - Milano
> tel. +39 02 2399 7130 - fax: +39 02 700 442 399
>