Wilhelm Meier:
> > Can you try 'ls -l /mnt/test/A' in this stiuation?
> > I thinks we should check the unionfs on nfs client side first.
> 
> The new results:
> 
> gs ~ #
> gs ~ # touch /tftproot/gentoo_B/x
> gs ~ # ls -l /tftproot/gentoo_B/x
> -rw-r--r--  1 root root 0 Dec 14 01:34 /tftproot/gentoo_B/x
> gs ~ # ls -l /mnt/test/A/x
> ls: /mnt/test/A/x: Operation not permitted
> gs ~ # ls -l /mnt/test/N/x
> -rw-r--r--  1 root root 0 Dec 14 01:34 /mnt/test/N/x
> gs ~ # ls -l /mnt/test/T/x
> ls: /mnt/test/T/x: No such file or directory
> gs ~ #                                              

What I wanted to know was readdir is abailable or not.
Is this EPERM too?


> Well, we modified file-metadata in the unification-fs, resulting in a 
> modification in the left-most rw-branch, which is /mnt/test/T in this case. 
> It succeds. If we delete the file in the left-most branch /mnt/test/T, then 
> the file should vanish if there are no other copies in the other branches, or 
> a file with same name of the other branches should show up. This should 
> happen here, I think, if I understand the semantics of the unification 
> correct. Am I wrong?

Unionfs tries to keep pointing the hidden dentry and inode, in this case
it means '/mnt/test/A/x points /mnt/test/T/x'. Removing /mnt/test/T/x,
the kept pointers in /mnt/test/A/x will not become illegal at that time,
since their reference counters are incremented.
I think unionfs will not follow down the lower branch (/mnt/test/N)
when the entry seems to be existing on the higher branch.
But actually the file does not exist any more. Finally ls shows the
un-exsisting information. The information which ls shows is kept in
inode.
(please correct me if i were wrong > anyone)


> Other situation would be, if we delete the file in the unification resulting 
> in a whiteout in the leftmost-rw-branch.

Whiteout is created when you remove the entry on unionfs. When you
remove the entry on a branch directly, whiteout is not created.


Junjiro Okajima
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs

Reply via email to