Am Mittwoch, 14. Dezember 2005 08:19 schrieb [EMAIL PROTECTED]: > 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?
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 *** ^ EPERM gs ~ # ls -l /mnt/test/A/ ls: /mnt/test/A/boot: Operation not permitted ls: /mnt/test/A/etc: Operation not permitted ls: /mnt/test/A/x: Operation not permitted ls: /mnt/test/A/bin: Operation not permitted ls: /mnt/test/A/home: Operation not permitted ls: /mnt/test/A/lib: Operation not permitted ls: /mnt/test/A/mnt: Operation not permitted ls: /mnt/test/A/opt: Operation not permitted ls: /mnt/test/A/root: Operation not permitted ls: /mnt/test/A/sbin: Operation not permitted ls: /mnt/test/A/tmp: Operation not permitted ls: /mnt/test/A/usr: Operation not permitted ls: /mnt/test/A/var: Operation not permitted ls: /mnt/test/A/dev: Operation not permitted ls: /mnt/test/A/proc: Operation not permitted ls: /mnt/test/A/sys: Operation not permitted ls: /mnt/test/A/stateless.sh: Operation not permitted total 0 gs ~ # ls -lad /mnt/test/A drwxrwxrwt 19 root root 40 Dec 14 02:40 /mnt/test/A gs ~ # *** ^ OK > > > 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. That's what I meant. > > > Junjiro Okajima > _______________________________________________ > unionfs mailing list > [email protected] > http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs -- -- Wilhelm Meier email: [EMAIL PROTECTED] _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
