> + touch /b/1/x1
> touch: cannot touch `/b/1/x1': Permission denied
:::
> Oct 11 11:12:25 fs8 kernel: unionfs_permission:876: mask 3
> Oct 11 11:12:25 fs8 kernel: unionfs_permission:910: bindex 1, is_file 0,
> hi{i4, 0040755, 0, 0}, fs{0, 0}, err -30
> Oct 11 11:12:25 fs8 kernel: inode_permission:833: mask 3
> Oct 11 11:12:25 fs8 kernel: inode_permission:857: i_op->perm c01b9a60
> Oct 11 11:12:25 fs8 kernel: inode_permission:860: retval -13
> Oct 11 11:12:25 fs8 kernel: unionfs_permission:918: err -13
This permission check is for /b/1/ is writable or not.
unionfs_permission() finds it is mounted as readonly and my patch show
-30(EROFS). Then unionfs_permission() calls inode_permission() and
nfs_permission() which is addressed c01b9a60, and it returns -13(EPERM).
Finally unionfs_permission() returns -13 as '/b/1/ is not writable' and
touch(1) failed.
Under the environment of (linux before 2.6.12 + current unionfs), it is
hard to say that this is a unionfs bug. Since current version of
nfs_permission() returns what unionfs expects.
The writable checking to a dir in nfs_permission() has been changed like
this,
- before 2.6.12
it asks the nfs server (and gets EPERM as you see).
- 2.6.12 and later
it always returns OK in order to reduce nfs traffics.
If you use newer linux,
- you will pass the unionfs_permission/inode_permission/nfs_permission
tests successfully.
- unionfs_create() will copyup the /b/1/ and create the file
successfully. As you know this is not a write to nfs.
This might be a problem of 'what linux version does unionfs suppport?'
Anyway current inode_permission() returns EPERM as it is expected.
If you cannot update your kernel, your solution is to use older version
of unionfs, unfortunately. Or modified version of unionfs.
Junjiro Okajima
_______________________________________________
unionfs mailing list
unionfs@mail.fsl.cs.sunysb.edu
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
