From owner-freebsd-fs@FreeBSD.ORG Tue Aug 23 10:27:30 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A2A106566B for ; Tue, 23 Aug 2011 10:27:30 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BBB3D8FC08 for ; Tue, 23 Aug 2011 10:27:29 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QvoCe-0008U6-Cw for freebsd-fs@freebsd.org; Tue, 23 Aug 2011 12:27:28 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Aug 2011 12:27:28 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Aug 2011 12:27:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Vadim Goncharov Date: Tue, 23 Aug 2011 10:27:14 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 53 Message-ID: References: <1092971110.92110.1313782831745.JavaMail.root@erie.cs.uoguelph.ca> <20110820145112.Y872@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Bruce Evans User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: touch(1) not working on directories in an msdosfs(5) envirement X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:27:30 -0000 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]