kern/106255: [msdosfs] : correct setting of archive flag

[Rene Ladan]

The following reply was made to PR kern/106255; it has been noted by GNATS.

From: Rene Ladan <r.c.ladan at gmail.com>
To: Bruce Evans <bde at zeta.org.au>
Cc: freebsd-gnats-submit at FreeBSD.org,  freebsd-bugs at FreeBSD.org
Subject: Re: kern/106255: [msdosfs] : correct setting of archive flag
Date: Mon, 04 Dec 2006 10:37:37 +0100

 Bruce Evans schreef:
 > On Sun, 3 Dec 2006, Rene Ladan wrote:
 > 
 >>> Description:
 >> The MSDOS file system has an archive bit in the flags field.  This bit
 >> roughly corresponds to the archive flag on the UFS file system. 
 >> However, it is set the wrong way around: the flag should be set when
 >> the bit is present, and cleared when the bit is absent.
 > 
 > The comment in msdosfs/direntry.h says that ATTR_ARCHIVE means that
 > the file is new or modified (in other words, not archived), while the
 > comment in sys/stat.h says that SF_ARCHIVED means that the file is
 > archived, but I think both mean that it is archived.
 > 
 Indeed, the MSDOS archive bit means that the user should archive the file.
 
 >> --- msdosfs_vnops.c    Mon Nov  6 14:41:57 2006
 >> +++ msdosfs_vnops.c.rene    Sun Dec  3 11:58:47 2006
 >> @@ -352,7 +352,7 @@
 >>         vap->va_ctime = vap->va_mtime;
 >>     }
 >>     vap->va_flags = 0;
 >> -    if ((dep->de_Attributes & ATTR_ARCHIVE) == 0)
 >> +    if (dep->de_Attributes & ATTR_ARCHIVE)
 >>         vap->va_flags |= SF_ARCHIVED;
 >>     vap->va_gen = 0;
 >>     vap->va_blocksize = pmp->pm_bpcluster;
 > 
 > This only fixes the reporting of the flag.  msdosfs still maintains
 > the flag perfectly backwards (except DETIMES() is missing setting of
 > it for for all changes -- I think all changes to metadata except
 > possibly to atimes should set it to be perfectly backwards and clear
 > it to be correct).
 > 
 Thanks, I'll look into that.
 
 > Grep shows that this flag is negatively useful in FreeBSD.  No file
 > systems maintain it (except for getting it backwards in msdosfs).
 > All archiving utilities need to maintain it for it to be useful,
 > but none except tar even reference it (except possibly indirectly via
 > strtofflags(3)), and tar seems to just print it (indirectly via a
 > special version of strtofflags(3)).
 >
 That's up to the utilities.
 
 > Bruce
 > 
 
 Regards,
 Rene
 -- 
 GPG fingerprint = E738 5471 D185 7013 0EE0  4FC8 3C1D 6F83 12E1 84F6
 (subkeys.pgp.net)
 
 "It won't fit on the line."
 		-- me, 2001