On Thu, 2015-12-17 at 07:21 +0100, Justus Winter wrote:
> Hi :)
>
> Quoting Svante Signell (2015-12-16 20:54:24)
> > I'd like to derive a test case for partial file locking with libnetfs:
> > Setting
> > up ftpfs and reading e.g. cat ftp://ftp.gnu.org/README works fine. But
> > open() on
> > that file returns EBADF.
>
> If you can cat it, then open works fine. How else would cat be able
> to open the file? I guess your open testcase fails because it tries
> to open the file writable, which you don't have permissions for on the
> gnu server. When in doubt, rpctrace is your friend.
I've tested the updated libnetfs code with and without opening with the write
flag:
int fd = open("ftp://ftp.gnu.org/README";, O_RDONLY);
works-> test_lockf_on_ftpfs: fcntl() failed: error = Permission denied (EACCES)
int fd = open("ftp://ftp.gnu.org/README";, O_RDWR);
-> fails test_lockf_on_ftpfs: fcntl() failed: error = Bad file descriptor
(EBADF)
Looking at the rpctrace output reveals that the issue is of course: Permission
denied (EACCES).
Without the patched libnetfs both cases returns:
test_lockf_on_ftpfs: fcntl() failed: error = Operation not supported
(EOPNOTSUPP)
So the code works, the only problem is that the files cannot be opened with the
write flag, as you wrote.
Setting struct flock fl: fl.l_type to F_RDLCK instead of F_WRLCK the patched
libnetfs code works fine :)
> > Other translators using libnetfs are: cvsfs, gohperfs, httpfs, mboxfs, nfs,
> > procfs, tarfs, xmlfs.
>
> Well, most of them are remote file systems. Providing the required
> locking semantics will be somewhere between tricky and impossible
> anyways (I remember you mentioning the need for a new proc api).
The current problem is that the partial file locks are inherited by a fork, and
they shouldn't. A new proc_user/server_authenticate RPC pair is needed. I'll
look more into that (with community help) after adding support for partial file
locking also for libtrivfs-based translators, like /dev/null.
> I believe NFS allows for distributed locking, but I'm not sure it's
> worth the effort. Any translator that doesn't do writes doesn't need
> locking anyway, and some of the translators are likely more prototypes
> than anything else (e.g. xmlfs).
Well, NFS or some other case is for future investigations then :)
