There are a small number of features that are missing from the VFS
interface (and hence from the FUSE interface), that are needed to
allow a special class of filesystems to provide a full UNIX (Posix,
SUS, whatever) file semantics.
The filesystems in question are served by a process that runs
- in userspace
- without special privileges
A trivial example is sshfs (sftp-server runs on remote server with
normal user privileges).
The limitations are:
1) open("foo", O_CREAT | O_WRONLY, 0444) or similar won't work
2) ftruncate on a file not having write permission (but file opened
in write mode) will fail
3) statfs() cannot return different values based on the path within
a filesystem
1) and 2) arise from the fact, that the VFS separates the permission
checking from the actual operations while the above described
filesystem can't do that.
1) can be solved by allowing a create+open atomic operation. The
infrastructure for this is already in -mm from the NFS tree.
2) can be solved by distinguishing ftruncate() from trunate() invoked
->setattr(). For ftruncate() the filesystem also needs to find a
handle for a file opened for writing. The file on which ftuncate()
was performed is always a good candidate, so an obvious solution is to
pass the open file to ->setattr().
3) comes from the fact that ->statfs() is a sb operation not an inode
operation. The only place where this is used is in sys_ustat() which
is deprecated and also useless for virtual (non disk based)
filesystems. So introduce a i_op->statfs() operation, which if
implemented will be used instead of s_op->statfs().
Changes to VFS:
1 - pass file pointer to ->setattr() if invoked from ftruncate()
2 - per inode statfs (core)
3 - per inode statfs (architectures)
Changes to FUSE:
4 - bump interface minor version
5 - add access call to interface
6 - atomic open+create
7 - pass file handle to userspace in setattr call
8 - per inode statfs (fuse)
Miklos
On Mon, Oct 24, 2005 at 06:45:05PM +0200, Miklos Szeredi wrote:
> The limitations are:
>
> 1) open("foo", O_CREAT | O_WRONLY, 0444) or similar won't work
>
> 2) ftruncate on a file not having write permission (but file opened
> in write mode) will fail
>
> 3) statfs() cannot return different values based on the path within
> a filesystem
4) mass of a body cannot vary depending on the way it's turned.
Horrible limitations, all of them...
> > The limitations are:
> >
> > 1) open("foo", O_CREAT | O_WRONLY, 0444) or similar won't work
> >
> > 2) ftruncate on a file not having write permission (but file opened
> > in write mode) will fail
> >
> > 3) statfs() cannot return different values based on the path within
> > a filesystem
>
> 4) mass of a body cannot vary depending on the way it's turned.
>
> Horrible limitations, all of them...
Troll.
We have solution for 1-3, what's your's for 4?
Miklos
> > > The limitations are:
> > >
> > > 1) open("foo", O_CREAT | O_WRONLY, 0444) or similar won't work
> > >
> > > 2) ftruncate on a file not having write permission (but file opened
> > > in write mode) will fail
> > >
> > > 3) statfs() cannot return different values based on the path within
> > > a filesystem
> >
> > 4) mass of a body cannot vary depending on the way it's turned.
> >
> > Horrible limitations, all of them...
>
> Troll.
>
> We have solution for 1-3, what's your's for 4?
And in case you're wondering, 1-2 are mandated by SUS, and obscure
programs like "cp" depend on 1) for example. So it's not as if these
limitations were all that fair.
Miklos
On Tue, Oct 25, 2005 at 07:56:46AM +0200, Miklos Szeredi wrote:
> > > The limitations are:
> > >
> > > 1) open("foo", O_CREAT | O_WRONLY, 0444) or similar won't work
> > >
> > > 2) ftruncate on a file not having write permission (but file opened
> > > in write mode) will fail
> > >
> > > 3) statfs() cannot return different values based on the path within
> > > a filesystem
> >
> > 4) mass of a body cannot vary depending on the way it's turned.
> >
> > Horrible limitations, all of them...
>
> Troll.
Sarkasm
> We have solution for 1-3, what's your's for 4?
Dunno - you are the one interested in solving non-problems...
On Tue, Oct 25, 2005 at 09:04:21AM +0200, Miklos Szeredi wrote:
> > > > The limitations are:
> > > >
> > > > 1) open("foo", O_CREAT | O_WRONLY, 0444) or similar won't work
> > > >
> > > > 2) ftruncate on a file not having write permission (but file opened
> > > > in write mode) will fail
> > > >
> > > > 3) statfs() cannot return different values based on the path within
> > > > a filesystem
> > >
> > > 4) mass of a body cannot vary depending on the way it's turned.
> > >
> > > Horrible limitations, all of them...
> >
> > Troll.
> >
> > We have solution for 1-3, what's your's for 4?
>
> And in case you're wondering, 1-2 are mandated by SUS, and obscure
> programs like "cp" depend on 1) for example. So it's not as if these
> limitations were all that fair.
(1) and (2) are real, no arguments here. It's statfs one that is
bogus (and yes, I should've trimmed the quoted part better).
> > > > > The limitations are:
> > > > >
> > > > > 1) open("foo", O_CREAT | O_WRONLY, 0444) or similar won't work
> > > > >
> > > > > 2) ftruncate on a file not having write permission (but file opened
> > > > > in write mode) will fail
> > > > >
> > > > > 3) statfs() cannot return different values based on the path within
> > > > > a filesystem
> > > >
> > > > 4) mass of a body cannot vary depending on the way it's turned.
> > > >
> > > > Horrible limitations, all of them...
> > >
> > > Troll.
> > >
> > > We have solution for 1-3, what's your's for 4?
> >
> > And in case you're wondering, 1-2 are mandated by SUS, and obscure
> > programs like "cp" depend on 1) for example. So it's not as if these
> > limitations were all that fair.
>
> (1) and (2) are real, no arguments here. It's statfs one that is
> bogus (and yes, I should've trimmed the quoted part better).
OK, let's say it's bogus.
I still believe, the one local filesystem - many remote filesystems is
a valid model, but it's pretty low priority. But it'll come back yet!
Miklos