From owner-freebsd-hackers Thu May 25 14:15:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 7DC3637B5E9 for ; Thu, 25 May 2000 14:15:22 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115206>; Fri, 26 May 2000 07:15:23 +1000 Content-return: prohibited From: Peter Jeremy Subject: Re: file creation times ? In-reply-to: <200005250821.JAA00580@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Thu, May 25, 2000 at 07:03:56PM +1000 To: Brian Somers Cc: hackers@FreeBSD.ORG Message-Id: <00May26.071523est.115206@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <200005250821.JAA00580@hak.lan.Awfulhak.org> Date: Fri, 26 May 2000 07:15:22 +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-May-25 19:03:56 +1000, Brian Somers wrote: >Of course access timestamps are usually useless anyway as most (?!!) >people will back up their system from time to time.... OOPS ! I >never realised before now - dump *doesn't* update the access time. This is because dump bypasses the filesystem (it reads the underlying device). Therefore the filesystem doesn't see the access. Other backup tools (tar, pax, cpio etc) access the files through the FS amd therefore alter the access time. Some have the ability to reset the access time afterwards - but that updates the change time, which is probably worse. This is probably good justification for a O_NOTACCESS (ie, this isn't a real access) flag on open(2) to request that the access time isn't updated. In general, access time is probably the least important of the timestamps. This is reflected in the treatment of access time updates - unlike all other inode updates, they are not written synchronously (non-softupdates) and don't affect soft-updates write-ordering (so atime updates can be lost). As I see it, the major use of access times would be for a true hierarchical storage manager (which transparently migrated un- referenced files to a tape-library or similar). It's also good for things like deleting `old' files in /tmp. >> As far as I'm concerned, you still haven't demonstrated any real >> need or justification for a creation timestamp. That said, >> there's nothing stopping you adding a creation timestamp to the >> UFS and providing patches. > >This should be trivial if added to the directory itself and should be >fully ``option''d in the kernel :-) I think the kernel changes would be fairly trivial, but there'd need to be fairly extensive userland changes. And you'd need to change various archive formats (tar, dump, ...) to support it. >If the format of the directory with this option enabled became >/ then the code could allow non-creation-time >filesystems to be mounted as creation-time filesystems and could >just add the timestamp to new files (by asserting that the existence >of the '/' means there's a timestamp next). I'm not sure what you mean here. Are you suggesting that the d_name begins '/XXXX' where XXXX is a binary timestamp? This sounds horrible. If we did go down this path, my preference would be something like: union direct { struct direct_old o; struct direct_new n; }; struct direct_old { u_int32_t d_ino; /* inode number of entry */ u_int16_t d_reclen; /* length of this record */ u_int8_t d_type; /* file type, see below */ u_int8_t d_namlen; /* length of string in d_name */ char d_name[MAXNAMLEN + 1];/* name with length <= MAXNAMLEN */ }; struct direct_new { u_int32_t d_ino; /* inode number of entry */ u_int16_t d_reclen; /* length of this record */ u_int8_t d_type; /* file type, see below */ u_int8_t d_namlen; /* length of string in d_name */ u_int32_t d_crtime; /* Entry creation time */ u_int32_t d_crtimensec; /* Entry creation time */ char d_name[MAXNAMLEN + 1];/* name with length <= MAXNAMLEN */ }; Where the top bit of d_type choses between them (if set then it's a new style entry). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message