Sudden change of file type

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

Sudden change of file type

Antonio SJ Musumeci
I'm using the high level libfuse API.

Lookup/getattr is called on a file and I return that it's a regular file. On a chmod/setattr I change the mode (say, from ugo=rw to ugo=r) and in the getattr side of the setattr I return that it's a symlink.

What I observe is that fchmodat in the chmod tool returns -1 (EIO). 

I'm guessing FUSE or the VFS doesn't accept that kind of sudden change? Is there anything in the high level libfuse API that would provide me some context in getattr to know from where it's being called? That it's from chown/setattr rather than on it's own? That way I can only return the new type on individual calls?

Thanks,

-antonio

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Sudden change of file type

Jean-Pierre André
Antonio SJ Musumeci wrote:
> I'm using the high level libfuse API.
>
> Lookup/getattr is called on a file and I return that it's a regular
> file. On a chmod/setattr I change the mode (say, from ugo=rw to ugo=r)
> and in the getattr side of the setattr I return that it's a symlink.

Do you mean the chmod/setattr and getattr entries in your
user space file system ? If so, changing to a symlink is
a voluntary action of your file system.

>
> What I observe is that fchmodat in the chmod tool returns -1 (EIO).
>
> I'm guessing FUSE or the VFS doesn't accept that kind of sudden change?

I have a similar situation in ntfs : creating a symlink is
sometimes done by setting a "reparse point" to a void file
or directory (so, creating such symlinks changes the type
of an inode, without fuse or the vfs being aware of the
change).

To avoid confusion in fuse or vfs, I just do a chown() from
the application which requested the symlink to be made,
this synchronizes the file type across the route.

> Is there anything in the high level libfuse API that would provide me
> some context in getattr to know from where it's being called? That it's
> from chown/setattr rather than on it's own? That way I can only return
> the new type on individual calls?
>
> Thanks,
>
> -antonio



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Sudden change of file type

Antonio SJ Musumeci
> Do you mean the chmod/setattr and getattr entries in your
> user space file system ? If so, changing to a symlink is
> a voluntary action of your file system.

Yes. In my particular case I've a passthrough / union fs. The thought was to offer a mode in which it would union the directories but return symlinks to the original files in certain conditions. (Versus doing passthrough of all read/writes.) In my test code I was doing that only when the underlying file was read only. The intent is to increase the read / rewrite speeds at the expense of an odd looking setup.

So in my code, in getattr, I lstat the file in question and if it's read only return that it's a symlink and in readlink I perform the same check and pass back the relevant data. It works fine till I chmod ugo=r an existing file. The call ultimately succeeds but from the process making the original chmod call receives -1 (EIO).


On Fri, May 6, 2016 at 2:52 AM, Jean-Pierre André <[hidden email]> wrote:
Antonio SJ Musumeci wrote:
> I'm using the high level libfuse API.
>
> Lookup/getattr is called on a file and I return that it's a regular
> file. On a chmod/setattr I change the mode (say, from ugo=rw to ugo=r)
> and in the getattr side of the setattr I return that it's a symlink.

Do you mean the chmod/setattr and getattr entries in your
user space file system ? If so, changing to a symlink is
a voluntary action of your file system.

>
> What I observe is that fchmodat in the chmod tool returns -1 (EIO).
>
> I'm guessing FUSE or the VFS doesn't accept that kind of sudden change?

I have a similar situation in ntfs : creating a symlink is
sometimes done by setting a "reparse point" to a void file
or directory (so, creating such symlinks changes the type
of an inode, without fuse or the vfs being aware of the
change).

To avoid confusion in fuse or vfs, I just do a chown() from
the application which requested the symlink to be made,
this synchronizes the file type across the route.

> Is there anything in the high level libfuse API that would provide me
> some context in getattr to know from where it's being called? That it's
> from chown/setattr rather than on it's own? That way I can only return
> the new type on individual calls?
>
> Thanks,
>
> -antonio



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel