NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: setting file creation time of a date

Hi Robert,

thanks to you and other for the reply.

Robert Elz wrote:
     Date:        Thu, 30 Apr 2020 12:21:18 +0200
     From:        Riccardo Mottola <>
     Message-ID:  <>

   | But can I set the creation time? I'd like to be able to preserve it when
   | dealing with files.

As Johhny Billquist said, the standard technique is to set the modtime
to the value you want the birthtime to be, and then set the modtime to
the value you want it to be (call utimes() (or one of its variants) twice).

I will attempt that!

But I wouldn't bother, the birthtime field is useless.

For example, whether it should be preserved when dealing with files
depends entirely upon what you're doing - if you're making a backup of
x.c in a file called old-x.c ("cp x.c old-x.c") then it probably makes
sense, but if you're using x.c as a template for new code, to get the
boilerplate parts correct ("cp x.c  newfile.c") then you almost certainly

My deal is exactly doing a backup.
I am author of a tree sync tool with GUI which I use with success since quite some time, StepSync [*]

The file creation can be quite useful. It can be used to preserve the original order, of logs, crashes, or anything. If the file is immutable, there is no difference (e.g. you don't usually edit a log file).

But suppose you have pictures of your camera: the creation date is the taking date, so you can easily order them and also see if the file was modified (e.g. edited in a program) by checking the difference!

This is not only useful, but worth to preserve.

Of course, it is of lesser use for the backup program itself, where you check for last modification date, still I am thinking of adding some additional checks for it.

I have previously asked people to tell me what they believe the semantics of
the birthtime are, and how that is useful for something - no-one has ever
succeeded in providing semantics that can be made to work, and which are
simultaneously useful.   It's easy to specify how the field can be set
but for those cases it there are no uses beyond human curiosity ("What was
the birthtime set to?") - there are uses to which a good file creation time
could be put, but no known reliable way to make the field actually work
reliably for those uses.

I would have proposed to have a specific call or to have a struct with two fields in utime, one of the two being null would preserve the value.



Home | Main Index | Thread Index | Old Index