touch(1) not working on directories in an msdosfs(5) envirement

Vadim Goncharov vadim_nuclight at mail.ru
Tue Aug 23 10:27:30 UTC 2011


Hi Bruce Evans! 

On Sat, 20 Aug 2011 16:44:59 +1000 (EST); Bruce Evans wrote about 'Re: touch(1) not working on directories in an msdosfs(5) envirement':

> The above is only the least serious of the bugs in msdosfs_setattr() :-(.
> With the above fix, plain touch works as well as possible -- it cannot
> work perfectly since setting of atimes is not always supported.  But
> touch -r and more importantly, cp -p only work as well as possible for
> root, since they use utimes() without the null timeptr arg that allows
> plain touch to work.  A non-null timeptr arg ends up normally requiring
> root permissions for msdosfs where it normally doesn't require extra
> permissions for ffs, because ownership requirements for the non-null case
> cannot be satisfied by file systems that don't really support ownerships.
> We fudge the ownerships and use weak checks on them  in most places, but
> for utimes() we use strict checks that almost always fail: from my old
> version:

So, now the usual case of not touching directory times on change is preserved,
but cp -r et al. sets times as expected? Sounds good, could it be committed
please?

> % file=z
> % ...
> % atime=Sat Aug 20 00:00:00 2011 (1313762400.0)
> % ctime=Sat Aug 20 16:14:29 2011 (1313820869.740000000)
> % mtime=Sat Aug 20 16:14:28 2011 (1313820868.0)

> This has the expected 2-second granularity for the mtime, but the other
> times are strange:
> - the atime is far in the past, and according to other tests has a
>    granularity of at least 200 seconds
> - the ctime has a granularity of 100 msec.  This differs significantly
>    from the mtime's granularity, so the ctime is up to 1.99 seconds in
>    advance of the mtime.  This is probably a local bug -- I probably
>    don't have the fix for confusion between the ctime and the creation
>    time (birthtime).  msdosfs only has a creation time so the ctime must
>    be faked and should usually be the same as the mtime.  But how does
>    the creation time have more precision?
> In other tests, creat() of a file sets the mtime and ctime reasonably,
> but the atime remains with a fixed value far in the past.  touch
> advances the mtime correctly, but doesn't update the ctime.  This is
> consistent with displayed ctime actually being the creation time.

That's a brainfart problem of FAT designers. There were not enough bytes
in directory entry, so for atime there is just 2 bytes - only date is stored,
no time at all. And for ctime there was added more granularity while it is
needed - one usually needs more granularity for atime than for fixed ctime.
BTW, that's already non-their problem, but ours: that's actually _btime_,
not ctime (Unices just had no btime ages ago).

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight at mail.ru
[Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]



More information about the freebsd-fs mailing list