Date: Sat, 20 Aug 2011 17:13:59 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: vadim nuclight <vadim_nuclight@mail.ru>, freebsd-fs@freebsd.org Subject: Re: touch(1) not working on directories in an msdosfs(5) envirement Message-ID: <20110820164559.Q872@besplex.bde.org> In-Reply-To: <1303085986.99226.1313794735324.JavaMail.root@erie.cs.uoguelph.ca> References: <1303085986.99226.1313794735324.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Aug 2011, Rick Macklem wrote:
> Vadim Goncharov wrote:
>> On Fri, 19 Aug 2011 15:40:31 -0400 (EDT); Rick Macklem wrote about
>> ...
>>> 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.
In a previous reply, I might have misremembered the limitations of
old FAT on directories. Now ISTR something before (?) FAT12 which only
had the root 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...).
This is the intentional part of msdosfs's compatibility.
> 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.
Me either, but I know cygwin can do most things (but it is so slow that
it is faster to reboot to run FreeBSD utilities to do anything involving
more than a few hundred files -- even a simple find -name takes 10-100
times longer in cygwin).
> 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;
> }
Yes, the special case for directories is just a bug (except for ATTR_ARCHIVE).
> 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.)
But this is msdosfs_setattr(), whose purpose is to update it. The
non-update for directory changes seems to be only here in detrunc():
% /*
% * Write out the updated directory entry. Even if the update fails
% * we free the trailing clusters.
% */
% dep->de_FileSize = length;
% if (!isadir)
% dep->de_flag |= DE_UPDATE|DE_MODIFIED;
% allerror = vtruncbuf(DETOV(dep), cred, td, length, pmp->pm_bpcluster);
I don't quite understand how extensions or changes in place either set or
avoid setting DE_MODIFIED -- grep didn't seem to show any relevant settings
-- maybe all cases go through detrunc().
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110820164559.Q872>