From owner-freebsd-fs@FreeBSD.ORG Tue Aug 23 10:11:05 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 8F693106566C for ; Tue, 23 Aug 2011 10:11:05 +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 1F32E8FC13 for ; Tue, 23 Aug 2011 10:11:04 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qvnwm-0002cL-3L for freebsd-fs@freebsd.org; Tue, 23 Aug 2011 12:11:04 +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:11:04 +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:11:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Vadim Goncharov Date: Tue, 23 Aug 2011 10:10:50 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 76 Message-ID: References: <1303085986.99226.1313794735324.JavaMail.root@erie.cs.uoguelph.ca> 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: Rick Macklem 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:11:05 -0000 Hi Rick Macklem! On Fri, 19 Aug 2011 18:58:55 -0400 (EDT); Rick Macklem wrote about 'Re: touch(1) not working on directories in an msdosfs(5) envirement': >>> Yes, FAT file systems do not maintain a directory modify >>> time. (The original FAT12,16 structure didn't even have a >>> modify time for the root dir.) >> >>> Just like Windows. >> >>> This causes issues when a FAT fs is exported via NFS and >>> someone was going to experiment with an "in memory only" >>> modify time for dirs, to minimize caching issues, but I >>> haven't heard back from them lately. >> >>> Apparently Mac OS X chooses to update the modify time that >>> exists on FAT32 file systems, but that isn't Windows compatible. >> >> What? I've just now created a test directory and changed it's modify >> time >> in Far Manager on Windows 2000, in a FAT32 partition. In fact it >> allows to >> change all three directory times, creation and access, too. So, I >> conclude, >> the FAT supports it. >> > Well, FAT32 (not the root dir of FAT12 or FAT16) does have a modify > time stored on disk for the directory entry for a directory. > The case I was thinking of (because that was what affected NFS client > caching) was the case where an entry is added to a directory. I just > checked that and it does not change the directory's modify time when > an entry is added to a directory (at least for Windows7 personal...). > I'm not enough of a Windows guy to even know what "Far Manager" is, > but I'm not surprised that there is a tool that can change it. That's a plugin-enabled console file two-panel file manager, of which, um, the Midnight Commander is just a cheap unperful buggy clone :-) But even this does not preserve directory times when directory trees are copied, yes. It just has a separate dialog to modify all file's attributes and times. I had to write a small Delphi program several years ago to make copying directory times from tree to tree. > msdosfs_setattr() in sys/fs/msdosfs/msdosfs_vnops.c definitely only > does it for non-directories: > if (vp->v_type != VDIR) { > if ((pmp->pm_flags & MSDOSFSMNT_NOWIN95) == 0 && > vap->va_atime.tv_sec != VNOVAL) { > dep->de_flag &= ~DE_ACCESS; > timespec2fattime(&vap->va_atime, 0, > &dep->de_ADate, NULL, NULL); > } > if (vap->va_mtime.tv_sec != VNOVAL) { > dep->de_flag &= ~DE_UPDATE; > timespec2fattime(&vap->va_mtime, 0, > &dep->de_MDate, &dep->de_MTime, NULL); > } > dep->de_Attributes |= ATTR_ARCHIVE; > dep->de_flag |= DE_MODIFIED; > } > I'm not the author of the above, but I had assumed that it was > because Windows doesn't normally update it. Obviously, the above > code could easily be changed (although I haven't tested that), if > that is now considered correct behaviour. (It might have been > because the msdosfs is meant to work for all FAT variants.) I don't know about other variants, nowhere to check :-) And Windows doesn't, yes. Windows lacks many standard tools and actions which are supported by API, though. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]