Re: [fuse-devel] Linux FUSE handling of utimensat(..., ..., NULL, ...)

[Derrik P. <de...@no...>]

Jean-Pierre:

2012/3/9 Jean-Pierre André <jea...@wa...>

> This shows that this is a fuse library issue and no patch
> to the kernel module is needed.


Well, yes, but it's sort of a cheat, because the actual update of the
timestamp does take place kernel-side based on the sb->s_time_gran value;
basically this just does something similar again in userspace, overriding
what the kernel's doing anyway. Which is fine, but (a) I don't think anyone
other than ntfs-3g is using fuse-lite, and (b) shouldn't the kernel driver
do the right thing for everyone, rather than depending on a sidestep in the
library?


> Actually setting the stamp
> to current time is done by the file system, and not based
> on a value sent from the kernel module... unless this
> has been superseded to fulfill a recent suggestion useful
> for restarting a frozen file system.


The case where times is passed as NULL is handled in the kernel by just
doing notify_change(), which updates the timestamp by calling
current_fs_time() like I mentioned (which sets the file timestamp based on
sb->s_time_gran). The setattr implementation in the fuse kernel module
(specifically in the iattr_to_fattr() function) sets flags that get passed
on to the userspace library that tell it what's actually being done, at
which point it just ignores the timestamp passed by the kernel and sets its
own (in fuse-lite). It seems like that's more work (to set the flag, set
the time at insufficient precision, then have to notice the flag and get
the time again in userspace) that way.

I was really just looking for a solution to the problem. Unfortunately
using fuse-lite for the Perl fuse bindings isn't really the best option.
I've thought about rewriting the Perl fuse bindings (or extending them with
a lowlevel interface option), but that's overkill for this. And really, the
right thing should be done for everyone - hence my raising the issue.

-- 
Derrik Pates
de...@no...