Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #236015 > unrolled thread

Creation vs Modification timestamps

Back to article view | Back to linux.debian.user

Contents

  Creation vs Modification timestamps "hobie of RMN" <hobie@rumormillnews.com> - 2021-06-12 06:30 +0200
    Re: Creation vs Modification timestamps Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-06-12 08:50 +0200
    Re: Creation vs Modification timestamps deloptes <deloptes@gmail.com> - 2021-06-12 11:00 +0200
    Re: Creation vs Modification timestamps Dan Ritter <dsr@randomstring.org> - 2021-06-12 12:50 +0200
      Re: Creation vs Modification timestamps Greg Wooledge <greg@wooledge.org> - 2021-06-12 15:10 +0200

#236015 — Creation vs Modification timestamps

Lately a script that has worked well and as intended for years and years
has begun doing something odd.  When archiving a bunch of flat files,
instead of keeping the creation timestamps on those files, it stamps them
with the date and time of their being moved.

Why that's happening is a separate issue and one that I do need to find
the answer to, but my question today is this:  Is it possible to find the
original creation date-and-time on these files, or is it simply "gone with
the wind" at this point?

--hobie

[toc] | [next] | [standalone]

#236016

[Multipart message — attachments visible in raw view] — view raw

Hi,

On 2021-06-12 12:19 a.m., hobie of RMN wrote:
> Lately a script that has worked well and as intended for years and years
> has begun doing something odd.  When archiving a bunch of flat files,
> instead of keeping the creation timestamps on those files, it stamps them
> with the date and time of their being moved.
> 
> Why that's happening is a separate issue and one that I do need to find
> the answer to, but my question today is this:  Is it possible to find the
> original creation date-and-time on these files, or is it simply "gone with
> the wind" at this point?
> 
> --hobie
> 

I'd say "Gone with the wind".

If you look at the specifications for all the different "ext2/3/4"
filesystem specifications, there's no place it says "store all the
passed date possible". What you see in ls -l is what's in the inode.
There's no secret hidden place with the dates of the file.

Except your original file shouldn't have had their date modified.
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development

[toc] | [prev] | [next] | [standalone]

#236019

hobie of RMN wrote:

> Why that's happening is a separate issue and one that I do need to find
> the answer to, but my question today is this:  Is it possible to find the
> original creation date-and-time on these files, or is it simply "gone with
> the wind" at this point?

I would say it is the root of the problem - share how you copy the files
If you use cp it is clearly wrong unless you use some of the options to
preserve the original time stamp. How it was working "for years" - I do not
know.

I use tar


$ ls -al TODO
-rw-r--r-- 1 user user 12475 Nov 22  2020 TODO

$ cp TODO /tmp/
ls -al /tmp/TODO
-rw-r--r-- 1 user user 12475 Jun 12 10:49 /tmp/TODO


$ tar cf - TODO | (cd /tmp/; tar xvf -)
TODO

$ ls -al /tmp/TODO
-rw-r--r-- 1 user user 12475 Nov 22  2020 /tmp/TODO

but if you use cp -a it has same effect

$ cp -a TODO /tmp/
$ ls -al /tmp/TODO
-rw-r--r-- 1 user user 12475 Nov 22  2020 /tmp/TODO

[toc] | [prev] | [next] | [standalone]

#236021

hobie of RMN wrote: 
> Lately a script that has worked well and as intended for years and years
> has begun doing something odd.  When archiving a bunch of flat files,
> instead of keeping the creation timestamps on those files, it stamps them
> with the date and time of their being moved.
> 
> Why that's happening is a separate issue and one that I do need to find
> the answer to, but my question today is this:  Is it possible to find the
> original creation date-and-time on these files, or is it simply "gone with
> the wind" at this point?

No. There are three timestamps, and none of them are original
creation times.

atime is last access time, and most modern systems have either
stopped recording this, or set it only when mtime is written.

mtime is last modification time, or if you prefer, the last time
it was written to.

ctime is not creation time; it is the last time the inode was
changed. ctime is updated when the permissions or ownership of
the file changes, or the number of links changes, or the number
of blocks changes...



-dsr-

[toc] | [prev] | [next] | [standalone]

#236027

On Sat, Jun 12, 2021 at 02:43:22AM -0400, Polyna-Maude Racicot-Summerside wrote:
> If you look at the specifications for all the different "ext2/3/4"
> filesystem specifications, there's no place it says "store all the
> passed date possible". What you see in ls -l is what's in the inode.
> There's no secret hidden place with the dates of the file.

This is incorrect.


On Sat, Jun 12, 2021 at 06:46:44AM -0400, Dan Ritter wrote:
> No. There are three timestamps, and none of them are original
> creation times.
> 
> atime is last access time, and most modern systems have either
> stopped recording this, or set it only when mtime is written.
> 
> mtime is last modification time, or if you prefer, the last time
> it was written to.
> 
> ctime is not creation time; it is the last time the inode was
> changed. ctime is updated when the permissions or ownership of
> the file changes, or the number of links changes, or the number
> of blocks changes...

Those are the POSIX file system semantics.  If you only look at the *sane*
parts of the Linux APIs, then that's all you'll be able to work with.
It's certainly all that's guaranteed across the various Unix-type file
systems.

However, ext4 actually *does* store a creation time.  It's hidden in a
field that isn't exposed via the normal stat(2) interface.  Virtually none
of the standard userland tools are able to see it.

On bullseye, stat(1) has been altered to make "birth" (a.k.a. creation)
time visible.  Here's a demonstration.  My home directory is on an ext4
file system with these mount options:

/dev/sda8 on /home type ext4 (rw,relatime)

unicorn:~$ rm x
unicorn:~$ echo x > x
unicorn:~$ sleep 5; chmod 600 x
unicorn:~$ stat x
  File: x
  Size: 2         	Blocks: 8          IO Block: 4096   regular file
Device: 808h/2056d	Inode: 803372      Links: 1
Access: (0600/-rw-------)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
Access: 2021-06-12 08:53:06.179415149 -0400
Modify: 2021-06-12 08:53:06.179415149 -0400
Change: 2021-06-12 08:53:20.391429504 -0400
 Birth: 2021-06-12 08:53:06.179415149 -0400

The "Change" line (ctime) is updated when the chmod runs, but the "Birth"
line is not.

unicorn:~$ echo y >> x
unicorn:~$ stat x
  File: x
  Size: 4         	Blocks: 8          IO Block: 4096   regular file
Device: 808h/2056d	Inode: 803372      Links: 1
Access: (0600/-rw-------)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
Access: 2021-06-12 08:53:06.179415149 -0400
Modify: 2021-06-12 08:53:40.787450117 -0400
Change: 2021-06-12 08:53:40.787450117 -0400
 Birth: 2021-06-12 08:53:06.179415149 -0400

Writing to the file updates the mtime and ctime fields, but not Birth.

Now, the bad news: if you're on buster or older, this won't work.  The
tools to work with ext4's Birth field simply didn't exist, or didn't
work.  And if you're on ext3 or many other file systems, these fields
simply don't exist in the file system, so it won't matter what tools
you use.

If you search the web, you can find other approaches to extracting the
Birth field on ext4 without working userland tools.  Many of them involve
running debugfs with sudo.  I wouldn't recommend doing this, other than
once as a proof of concept just to see that it does in fact "work".

The top answer on
<https://unix.stackexchange.com/questions/91197/how-to-find-creation-date-of-file>
gives some detailed explanations of how ugly this whole thing truly is.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web