[9fans] bind -c

[9fans] bind -c

[Sam]

I seem to be hitting all the rough edges today.

Why shouldn't this work?
	term% mkdir replica; cd replica
	term% bind -c . .
	term% bind -a /sys/src/cmd/replica .
	term% cp mkfile . #obtain a local copy
	cp: mkfile and mkfile are the same file

Sam

Re: [9fans] bind -c

[Russ Cox]

> Why shouldn't this work?
> 	term% mkdir replica; cd replica
> 	term% bind -c . .
> 	term% bind -a /sys/src/cmd/replica .
> 	term% cp mkfile . #obtain a local copy
> 	cp: mkfile and mkfile are the same file

Because the first thing cp does is basically

	ls -lq mkfile ./mkfile

and discovers that the source and destination
are the same.  Binding with -c only changes 
where _new_ files are created.  When you create()
an existing file that directory entry is used.

In this case it's probably significantly easier just to

	mkdir replica
	cp /sys/src/cmd/replica/* replica

and not worry about union directories.

What I usually do for things like this is:

	cd /sys/src/cmd/replica
	bind -bc $home/replica .

and then 

	cp mkfile $home/replica
	etc.

to make copies of the files I want to change.

Russ

Re: [9fans] bind -c

[Sam]

More useful might be a script rebind that
allows you to rebind a union'd directory D
with/without the creation bit by popping
off the ns elements after D then pushing
them back.

This is such a seldom done task that
I doubt it's really necessary, though.  If
you've screwed up your namespace creation
order, wipe it and start over.

I didn't realize until yesterday just
how poorly I understood union dirs & -c.
It became much clearer when Russ commented
that one used to have to start a union
directory D with bind D D, which is now
implicit (before the first bind, presumably).

Sam

Re: [9fans] bind -c

[Keith Nash]

It might be useful to have a 'bind -w' option, that would cause a union member to capture all write operations that would otherwise go to members that are 'after' it.  I suppose the problem is that if a file is opened for reading *and* writing, then the file would first have to be copied to the '-w' member; also the response to file deletion would have to be decided.

'bind -w' might cause more problems than it solves; but it seems sub-optimal that at present, if we want modified files to go to one union member, leaving the originals unchanged in another, we have to perform the 'copy-on-write' operation by manually copying files to a '-c' member - and we must do this (or at least create a file with the right name) even if only write access is required to the file, not read-and-write.  Also, it is obvious that we can only do this manual preparation if we know in advance the names of the files that will be written.

Another useful option might be 'bind -r', to switch off all types of write access to a member, not just file creation.


Keith.