Date: Fri, 26 May 2000 07:15:22 +1000 From: Peter Jeremy <peter.jeremy@ALCATEL.COM.AU> To: Brian Somers <brian@Awfulhak.org> Cc: hackers@FreeBSD.ORG Subject: Re: file creation times ? Message-ID: <00May26.071523est.115206@border.alcanet.com.au> In-Reply-To: <200005250821.JAA00580@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Thu, May 25, 2000 at 07:03:56PM %2B1000 References: <peter.jeremy@alcatel.com.au> <200005250821.JAA00580@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-May-25 19:03:56 +1000, Brian Somers <brian@Awfulhak.org> 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 <inode>
>/<timestamp><filename> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00May26.071523est.115206>