Messages in this thread | | | From | OGAWA Hirofumi <> | Subject | Re: utimensat fails to update ctime | Date | Tue, 22 Dec 2009 18:00:36 +0900 |
| |
Eric Blake <ebb9@byu.net> writes:
> According to OGAWA Hirofumi on 12/21/2009 8:05 AM: >>> It may also be file-system dependent. On the machine where I saw the >>> original failure: >>>> $ uname -a >>>> Linux fencepost 2.6.26-2-xen-amd64 #1 SMP Thu Nov 5 04:27:12 UTC 2009 >>>> x86_64 GNU/Linux >>> $ df -T . >>> Filesystem Type 1K-blocks Used Available Use% Mounted on >>> /dev/sdb1 xfs 419299328 269018656 150280672 65% /srv/data >> >> Thanks. >> >> This is good point. This would be xfs issue or design. xfs seems to have >> own special handling of ctime. > > Here's another report, this time about an mtime update not happening on > ntfs-3g. http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/19336
It is likely the issue of libfuse or ntfs-3g. I don't know about ntfs-3g people at all. So, for now, just Cc: to fuse people.
> utimensat(0, NULL, {UTIME_OMIT, UTIME_NOW}, 0) = 0
From this, "ia_valid" will have "ATTR_CTIME | ATTR_MTIME". And the request would pass to userland via fuse of kernel part, then it will be handled by libfuse.
From quick grep of libfuse and ntfs-3g (would not be latest), ntfs-3g is using "struct fuse_operations", not "struct fuse_lowlevel_ops".
So, fuse_lib_setattr() would be the handler for it in libfuse. And, from the following part, it seems to require the both of MTIME and ATIME to call ntfs-3g's ->utime handler.
I don't know whether it is limitation or bug in fuse_operations. Any ideas?
if (!err && (valid & (FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME)) == (FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME)) { struct timespec tv[2]; tv[0].tv_sec = attr->st_atime; tv[0].tv_nsec = ST_ATIM_NSEC(attr); tv[1].tv_sec = attr->st_mtime; tv[1].tv_nsec = ST_MTIM_NSEC(attr); err = fuse_fs_utimens(f->fs, path, tv); }
Thanks. -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
| |