Recalling how does hiding of files work

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

Recalling how does hiding of files work

Vincenzo Ciancia
Hi all,

Let me summarize the behaviour of fuse wrt open, release, read, write and
unlink, because my ocaml binding is out-of-date:

- if a file with path "path1" is opened, the program receives an open() call
with path1 as argument, and the caller receives "f" as file descriptor

- if path1 is then deleted, it's renamed to ".fuse_hiddenSOMETHING"

- if then the caller reads from "f", the program receives a read() call with
".fuse_hiddenSOMETHING" as argument

- if the caller closes "f" and it was the only one opening it, the program
receives a release() call with ".fuse_hiddenSOMETHING" as argument

Now, how can the program know what file ".fuse_hiddenSOMETHING" is referring
to? Does this mean that if I want to have any kind of stateful filesystem
(e.g. tracking how many open and release calls a file has had) I _have_ to
use the "fuse_file_info" argument? Also, wasn't there a "hide" operation
which told the new name of a file? And also, using the "fuse_file_info",
it's like I am using an inode based interface with the extra cluttering of
paths - am I right?

In 2.4 (yes I could also look into CVS :)), will the interfaces for the
inode based API and the path based API be separated? In that case, will the
"fuse_file_info" arguments be dropped? If not, won't this be a clone of the
inode based API?

Sorry for the confusion and thanks

Vincenzo

--
Please note that I do not read the e-mail address used in the from field but
I read vincenzo_ml at yahoo dot it
Attenzione: non leggo l'indirizzo di posta usato nel campo from, ma leggo
vincenzo_ml at yahoo dot it



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Recalling how does hiding of files work

Miklos Szeredi
> Let me summarize the behaviour of fuse wrt open, release, read, write and
> unlink, because my ocaml binding is out-of-date:
>
> - if a file with path "path1" is opened, the program receives an open() call
> with path1 as argument, and the caller receives "f" as file descriptor
>
> - if path1 is then deleted, it's renamed to ".fuse_hiddenSOMETHING"
>
> - if then the caller reads from "f", the program receives a read() call with
> ".fuse_hiddenSOMETHING" as argument
>
> - if the caller closes "f" and it was the only one opening it, the program
> receives a release() call with ".fuse_hiddenSOMETHING" as argument
>
> Now, how can the program know what file ".fuse_hiddenSOMETHING" is referring
> to? Does this mean that if I want to have any kind of stateful filesystem
> (e.g. tracking how many open and release calls a file has had) I _have_ to
> use the "fuse_file_info" argument?

Sort of.  You could keep track of open files as they are renamed, but
that's rather complicated.

> Also, wasn't there a "hide" operation which told the new name of a
> file? And also, using the "fuse_file_info", it's like I am using an
> inode based interface with the extra cluttering of paths - am I
> right?

File-handles are distinct from inodes, but there's a close
releationship: each file-handle refers to a single fixed inode, but
there could be many file-handles refering to the same inode.

> In 2.4 (yes I could also look into CVS :)), will the interfaces for the
> inode based API and the path based API be separated?

Yes.

> In that case, will the "fuse_file_info" arguments be dropped?

No.

> If not, won't this be a clone of the inode based API?

You'll now have 4 choices (instead of 2):

 1) stateless I/O using path based API, using path argument

 2) stateful I/O using path based API, using fuse_file_info argument

 3) stateless I/O using inode based API, using inode argument

 4) stateful I/O using inode based API, using fuse_file_info arguement

Arguably 2 and 4 are similar, but you can still make a choice between
the two APIs based on what you need for the other operations.

Miklos


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Recalling how does hiding of files work

Vincenzo Ciancia
Thanks for your reply. Also:

- using the inode-based API, does the need for .fuse_hidden files disappear?

- is there any way to change the name and the location of the hidden files?

- what happens if I get requests for one of the .fuse_hidden files from
userspace processes? What file handle will I get?

I think I should avoid showing in getdir any file starting with .fuse_hidden
(even this is a slight deviation from standard filesystem behaviour), and
also return an error on open() calls for paths beginning with .fuse_hidden.
Am I right? Could the kernel implementation avoid accepting open requests
for those files in principle, perhaps in a more efficient way?

bye

Vincenzo




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Recalling how does hiding of files work

Miklos Szeredi
> Thanks for your reply. Also:
>
> - using the inode-based API, does the need for .fuse_hidden files disappear?

Yes.

> - is there any way to change the name and the location of the hidden files?

No.

> - what happens if I get requests for one of the .fuse_hidden files from
> userspace processes? What file handle will I get?

The same as the one used before the file was unlinked.

> I think I should avoid showing in getdir any file starting with .fuse_hidden
> (even this is a slight deviation from standard filesystem behaviour), and
> also return an error on open() calls for paths beginning with .fuse_hidden.
> Am I right?

I don't think it's worth doing any of these.  If for example an open
file is unlinked in an otherwise empty directory, and then the user
tries rmdir() on that directory, it will get an ENOTEMPTY error.  It
just makes it more confusing if the user doesn't see what's causing
this.

> Could the kernel implementation avoid accepting open requests
> for those files in principle, perhaps in a more efficient way?

There's no harm in allowing open/unlink/etc.  They will behave
_exactly_ like normal files, except they will be deleted automatically
on the last release.

Miklos


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel