In message <[EMAIL PROTECTED]>, Michael Tokarev writes: > Daniel Reichelt wrote: > > Hi list, > > > > I have an unionfs mount setup like this: > > > > # mkdir br1 br2 rwunion > > # mount -t nfs -o ro server:/nfsexport /br2 > > # mount -t unionfs -o dirs=/br1=rw:/br2=ro none /rwunion/ > > > > So far so good. When I try to add new files or remove files that > > pre-existed on > > the ro-nfs branch, that works just fine. However appending/chaning files > > originating from the ro-nfs branch, I get this: > > > > # ls -la /br1 > > # ls -la /br2 > > -rw-r--r-- 1 root root 55 2008-11-06 04:41 test > > > > # ls -la /rwunion > > -rw-r--r-- 1 root root 55 2008-11-06 04:41 test > > > > # echo >test > > bash: test: Permission denied > > This is matches my expirence as well. Quite annoying sometimes... :) > > F.e., on a unionfs-root with one branch from read-only nfs and > another on tmpfs:
Are you using this w/ a livecd? If so, can I get an image to try and some instrux how to use it? > # apt-get update > apt: unable to open /var/lib/apt/lists/lock: Permission denied > # touch /var/lib/apt/lists/lock > # apt-get udpate > .. apt goes on successfully .. > > I.e., when opening a file residing on a read-only branch for > writing, unionfs returns EACCES, but touch'ing etc that file > makes a copy in a read-write branch, and opening THAT file > works. So looks like the open(O_WRITE) case when the file > is on the ro branch does not work as expected. > > But after thinking about this for a bit... the COW (Copy On Write) > should really be coW, not coO (copy on open). IMHO. I.e., to > let open(O_WRITE) to succeed, but to create the copy on first > real write, not on open. Oh well. That's what my code aims to do: defer CoW until it's definitely needed. So if you open a file w/ O_WRITE, then close it w/o performing any write, unionfs should NOT be copying up anything. (That was a fix to a bugzilla report from a while back.) Because the permission semantics of unionfs are different than a typical f/s, I had to use my own version of inode_permission; otherwise I can't distinguish b/t EROFS cases that should trigger copyups, and other permission problems that should not trigger copyups. Anyway, first I need to reproduce the problem you're seeing. I'm sure the fix will be a simple one (it's not like this bug is a race condition :-) Cheers, Erez. _______________________________________________ unionfs mailing list: http://unionfs.filesystems.org/ unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
