Re: setting file creation time of a date

[Riccardo Mottola <riccardo.mottola%libero.it@localhost>]

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 <riccardo.mottola%libero.it@localhost>
>      Message-ID:  <6a5beb80-729f-ddcf-6b12-70eb13d7e4e5%libero.it@localhost>
>
>    | 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
> don't.

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.


Riccardo

[*] http://gap.nongnu.org/stepsync/index.html