[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test case for partial file locking for translators using libnetfs.

From: Svante Signell
Subject: Re: test case for partial file locking for translators using libnetfs.
Date: Thu, 17 Dec 2015 12:21:04 +0100

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
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
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

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 :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]