Date: Tue, 23 Aug 2011 10:27:14 +0000 (UTC) From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-fs@freebsd.org Subject: Re: touch(1) not working on directories in an msdosfs(5) envirement Message-ID: <slrnj57041.30vs.vadim_nuclight@kernblitz.nuclight.avtf.net> References: <1092971110.92110.1313782831745.JavaMail.root@erie.cs.uoguelph.ca> <20110820145112.Y872@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnj57041.30vs.vadim_nuclight>