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

[Bruce Evans]

On Tue, 23 Aug 2011, Vadim Goncharov wrote:

> 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?

Yes, cp -p works but only if the user is root or the owner of the file.

Someone else will have to commit it.

>> % 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.

Ah, the missing seconds part of time is now clear in the FreeBSD sources
too -- a null pointer is used.  Now I wonder if this field is worth
supporting at all and whether the current support of it is the best use
of it (I guess there is nothing better than just writing the date and
compatibility requires this).  I normally mount with -noatime but am not
so careful about this for msdosfs.  FreeBSD could default to -noatime for
msodsfs or any file system where atimes are even less useful than usual.
OTOH, since the atimes only change every day, the -noatime option as a
means to prevent excessive writes is not very useful.  msdosfs already
has the optimization of not writing to disk for null changes to atimes.
I wondered why it didn't do this optimization for all null changes (my
version does).  Now I know.

> 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).

Bruce