O_CREAT in open()?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

O_CREAT in open()?

John Muir-3
Why isn't O_CREAT passed through to the open call in the FUSE library
(or from the kernel for that matter)?

I'd like to avoid a whole bunch of empty files on my underlying
file-system. Is there a way to handle this?

What would happen if I patched the kernel module to allow O_CREAT at
least to get through.

Thanks,

John.

--
John Muir
NORTEL
[hidden email]



-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: O_CREAT in open()?

Valient Gough
On Wednesday 25 May 2005 19:43, John Muir wrote:
> Why isn't O_CREAT passed through to the open call in the FUSE library
> (or from the kernel for that matter)?
>
> I'd like to avoid a whole bunch of empty files on my underlying
> file-system. Is there a way to handle this?


An open(... O_CREAT) gets turned into a mknod followed by an open.  Is your
open() failing?

A common problem is that open(..., O_RDWR | O_CREAT, 0222)  can create files
which do not have write access, yet it is valid to have them opened in
read-write mode.  So after the mknod you end up with a file that doesn't have
write permission, followed by a request to open for write.  But it seems this
question has to be revisited now if the default_permission flag disabled.

When fuse's default_permission flag is in effect, then the kernel has already
checked permissions before passing along the requests, so you can assume that
it is ok to proceed and open the file for write anyway.  But what happens if
default_permission is not in effect?  Then how do we know it is ok to open a
file for write when it doesn't allow write access?

Valient


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: O_CREAT in open()?

Miklos Szeredi
In reply to this post by John Muir-3
> Why isn't O_CREAT passed through to the open call in the FUSE library
> (or from the kernel for that matter)?

The way O_CREAT works in linux, is that if the file doesn't exist the
VFS calls the create() method, and then calls the open() method.  Open
will never actually have to create the file, so it doesn't need
O_CREAT.

> I'd like to avoid a whole bunch of empty files on my underlying
> file-system. Is there a way to handle this?

Why do you get empty files?

> What would happen if I patched the kernel module to allow O_CREAT at
> least to get through.

Nothing especially bad would happen.  Though I'm still curious why you
need O_CREAT at open() time.

Miklos


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: O_CREAT in open()?

John Muir-3
In reply to this post by Valient Gough
Valient Gough wrote:

>On Wednesday 25 May 2005 19:43, John Muir wrote:
>  
>
>>I'd like to avoid a whole bunch of empty files on my underlying
>>file-system. Is there a way to handle this?
>>    
>>
>An open(... O_CREAT) gets turned into a mknod followed by an open.  Is your open() failing?
>  
>
Ah! No. I didn't understand that open( O_CREAT ) means mknod followed by
open. Just jumping to conclusions. Thanks.

Maybe this needs to be added somewhere to doc/ or FAQ... or I should
read the code huh?

>A common problem is that open(..., O_RDWR | O_CREAT, 0222)  can create files which do not have write access, yet it is valid to have them opened in read-write mode.  So after the mknod you end up with a file that doesn't have write permission, followed by a request to open for write.  But it seems this question has to be revisited now if the default_permission flag disabled.
>
>When fuse's default_permission flag is in effect, then the kernel has already checked permissions before passing along the requests, so you can assume that it is ok to proceed and open the file for write anyway.  But what happens if default_permission is not in effect?  Then how do we know it is ok to open a file for write when it doesn't allow write access?
>  
>
I guess you'd have to stat that file yourself?

John.

--
John Muir
7Q27 - Typhoon Software
NORTEL
[hidden email]



-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: O_CREAT in open()?

John Muir-3
In reply to this post by Miklos Szeredi
Miklos Szeredi wrote:

>>Why isn't O_CREAT passed through to the open call in the FUSE library (or from the kernel for that matter)?
>>    
>>
>
>The way O_CREAT works in linux, is that if the file doesn't exist the VFS calls the create() method, and then calls the open() method.  Open will never actually have to create the file, so it doesn't need
>O_CREAT.
>
>  
>
>>I'd like to avoid a whole bunch of empty files on my underlying
>>file-system. Is there a way to handle this?
>>    
>>
>
>Why do you get empty files?
>  
>
I thought that I would need to do open(), followed by open(O_CREAT)
because I didn't realize that the open(O_CREAT) by a user was translated
to FUSE mknod followed by FUSE open.

Thanks,

John.

--
John Muir
NORTEL
[hidden email]



-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: O_CREAT in open()?

Miklos Szeredi
In reply to this post by Valient Gough
> But what happens if default_permission is not in effect?  Then how
> do we know it is ok to open a file for write when it doesn't allow
> write access?

Well, an ACCESS method could be introduced, which would get called
before OPEN and by access().

In fact the kernel calls the filesystem's permission() method before
every operation (except getattr()), but for other operations it does
not buy us anything to make two requests instead of just one.

With OPEN, this is the only way the permission checking can correctly
be done if not using 'default_permission'.

Does this make sense?

There's still problem with filesystems (like sshfs) which cannot check
open permission before actually opening the file.

The solution would be if the kernel could pass this information
(permission check needed/not needed) to open.  Currently this is not
available, but it would be simple enough to modify the VFS to allow
this.

Miklos


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel