From: David S. <ds...@ja...> - 2004-05-11 21:26:40
|
I am using fuse_get_context() to get the uid and gid of the process making the file access call, and this worked fine for write and truncate. Now I'd like to do it in release, but always get a uid and gid of 0. Any reason why? David |
From: Mattias W. <ma...@su...> - 2004-05-11 22:24:05
|
Took a fast look at the code and saw that kernel/file.c:fuse_release use a pointer insted of a local fuse_in struct initialized with FUSE_IN_INIT (this macro includes current->fsuid etc), so this is probably the reason. Also saw that kernel/inode.c:fuse_clear_inode (the forget operation) does the same, so probably the some behavior there. Dont really know how to fix this in a nice way. Miklos and others: Is there good reason why to use pointers and alloc memory insted of useing a local struct in these functions? -Mattias On Tue, 11 May 2004 17:26:31 -0400 David Shaw <ds...@ja...> wrote: > I am using fuse_get_context() to get the uid and gid of the process > making the file access call, and this worked fine for write and > truncate. > > Now I'd like to do it in release, but always get a uid and gid of 0. > Any reason why? > > David > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver > higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > Avf-fuse-dev mailing list > Avf...@li... > https://lists.sourceforge.net/lists/listinfo/avf-fuse-dev > |
From: <Mik...@et...> - 2004-05-12 11:21:06
|
> Took a fast look at the code and saw that kernel/file.c:fuse_release > use a pointer insted of a local fuse_in struct initialized with > FUSE_IN_INIT (this macro includes current->fsuid etc), so this is > probably the reason. Also saw that kernel/inode.c:fuse_clear_inode > (the forget operation) does the same, so probably the some behavior > there. > > Dont really know how to fix this in a nice way. > > Miklos and others: Is there good reason why to use pointers and > alloc memory insted of useing a local struct in these functions? Yes: RELEASE and FORGET are asynchronous, so the the function returns before the request is processed. The uid/gid fields could be filled in on release though, but as Cody said, release can have differing uid/gid than open. Why do you need uid/gid in release? Miklos |
From: David S. <ds...@ja...> - 2004-05-14 18:36:33
|
On Wed, May 12, 2004 at 01:20:45PM +0200, Miklos Szeredi wrote: > > > Took a fast look at the code and saw that kernel/file.c:fuse_release > > use a pointer insted of a local fuse_in struct initialized with > > FUSE_IN_INIT (this macro includes current->fsuid etc), so this is > > probably the reason. Also saw that kernel/inode.c:fuse_clear_inode > > (the forget operation) does the same, so probably the some behavior > > there. > > > > Dont really know how to fix this in a nice way. > > > > Miklos and others: Is there good reason why to use pointers and > > alloc memory insted of useing a local struct in these functions? > > Yes: RELEASE and FORGET are asynchronous, so the the function returns > before the request is processed. > > The uid/gid fields could be filled in on release though, but as Cody > said, release can have differing uid/gid than open. Why do you need > uid/gid in release? My understanding of open & release is that for every open there is a corresponding release. Also, the flags that were used for a particular open are also used for a particular release, which gives a certain ability to tie a given open to a given release. So, I don't actually need it (since I can use the uid/gid provided by open, as you can't get to release without an open first), but I was playing around and noticed it was missing. David |
From: David S. <ds...@ja...> - 2004-05-14 18:45:29
|
On Wed, May 12, 2004 at 01:20:45PM +0200, Miklos Szeredi wrote: > Yes: RELEASE and FORGET are asynchronous, so the the function returns > before the request is processed. Hmm. So it doesn't matter what I return from my release function? I understand there is not an exact 1:1 relationship between close() and release, but I had hoped that a error return from release would be carried up as an error return from close(). David |
From: <Mik...@et...> - 2004-05-17 08:25:45
|
> > Yes: RELEASE and FORGET are asynchronous, so the the function returns > > before the request is processed. > > Hmm. So it doesn't matter what I return from my release function? I > understand there is not an exact 1:1 relationship between close() and > release, but I had hoped that a error return from release would be > carried up as an error return from close(). In release() the error value is ignored, and not every close will cause a release. Consider this: - process opens a file - process forks - parent closes the file - child closes the file The file will only be released on the second close, i.e. when all references to the file are closed. Also memory mapping a file creates a reference to the file, that is released when the memory is unmapped. There is a flush() operation in the VFS that is called on every close(), through which the filesystem can return an error. This operation is not yet exported in fuse, but if somebody needs it it's not hard to do. Miklos |
From: David S. <ds...@ja...> - 2004-05-17 20:45:59
|
On Mon, May 17, 2004 at 10:25:20AM +0200, Miklos Szeredi wrote: > > > > Yes: RELEASE and FORGET are asynchronous, so the the function returns > > > before the request is processed. > > > > Hmm. So it doesn't matter what I return from my release function? I > > understand there is not an exact 1:1 relationship between close() and > > release, but I had hoped that a error return from release would be > > carried up as an error return from close(). > > In release() the error value is ignored, and not every close will > cause a release. Consider this: > > - process opens a file > - process forks > - parent closes the file > - child closes the file > > The file will only be released on the second close, i.e. when all > references to the file are closed. Also memory mapping a file creates > a reference to the file, that is released when the memory is unmapped. > > There is a flush() operation in the VFS that is called on every > close(), through which the filesystem can return an error. This > operation is not yet exported in fuse, but if somebody needs it it's > not hard to do. That would be a huge help. I was going to try and fake what I needed though other calls, but the ability to pass an error back directly to close() is much much better. David |
From: <Mik...@et...> - 2004-05-18 08:48:06
|
> > close(), through which the filesystem can return an error. This > > operation is not yet exported in fuse, but if somebody needs it it's > > not hard to do. > > That would be a huge help. I was going to try and fake what I needed > though other calls, but the ability to pass an error back directly to > close() is much much better. Done. I've not tested it but it seems to be the simplest operation of all so I hope it works. Miklos |
From: David S. <ds...@ja...> - 2004-05-18 13:21:03
|
On Tue, May 18, 2004 at 10:47:38AM +0200, Miklos Szeredi wrote: > > > > close(), through which the filesystem can return an error. This > > > operation is not yet exported in fuse, but if somebody needs it it's > > > not hard to do. > > > > That would be a huge help. I was going to try and fake what I needed > > though other calls, but the ability to pass an error back directly to > > close() is much much better. > > Done. I've not tested it but it seems to be the simplest operation of > all so I hope it works. Thank you VERY much. I'll check this out today. Just so I fully understand, flush is called once for each open fd as part of the close() operation. Fuse itself handles the writing part of a flush, so it seems like a notification to the filesystem that a flush is taking place more than an instruction to flush. David |
From: <Mik...@et...> - 2004-05-18 13:40:22
|
> Thank you VERY much. I'll check this out today. OK, waiting for the bugreports ;) > Just so I fully understand, flush is called once for each open fd as > part of the close() operation. Yes. > Fuse itself handles the writing part of a flush, Actually no flush is taking place. Writing to a file with write() is synchronous, so every write() goes through to userspace (only broken down to page sized chunks). > so it seems like a notification to the filesystem that a flush is > taking place more than an instruction to flush. Well the naming is maybe misleading. It's probably called flush, because calling it 'close' would imply that the file is _finally_ closed, and not just dereferenced. It could be called dropfile or putfile or something silly like that, which would be less confusing. But flush sound better, and if it's not very important I'd rather not name the operation differently in the FUSE interface than in the VFS interface (which would confuse people familiar with the VFS). Miklos |
From: David S. <ds...@ja...> - 2004-05-18 19:27:00
|
On Tue, May 18, 2004 at 03:39:57PM +0200, Miklos Szeredi wrote: > > > Thank you VERY much. I'll check this out today. > > OK, waiting for the bugreports ;) So far, so good. One small patch for debugging prettiness: Index: fuse.c =================================================================== RCS file: /cvsroot/avf/fuse/lib/fuse.c,v retrieving revision 1.53 diff -u -r1.53 fuse.c --- fuse.c 18 May 2004 08:45:28 -0000 1.53 +++ fuse.c 18 May 2004 18:48:42 -0000 @@ -43,6 +43,7 @@ case FUSE_WRITE: return "WRITE"; case FUSE_STATFS: return "STATFS"; case FUSE_RELEASE: return "RELEASE"; + case FUSE_FLUSH: return "FLUSH"; case FUSE_FSYNC: return "FSYNC"; case FUSE_SETXATTR: return "SETXATTR"; case FUSE_GETXATTR: return "GETXATTR"; |
From: <Mik...@et...> - 2004-05-19 08:24:49
|
> So far, so good. One small patch for debugging prettiness: > Yep, I forgot that. Thanks! Miklos |