file modified/created dates

Today I downloaded a couple of install files to my downloads
directory. Later I brought up that directory and sorted it by "date
modified."

To my surprise, there was only one with today's date. I found the
other which under properties said:
Created: Today, Jan 1, 2019 3 minutes ago.
Modified: Sunday, December 30 2018, 2:31 PM.

How can it be modified before it is created? I have noticed this
inconsistency before, not just on this one file.

-dan z-



--
Someone who thinks logically provides
a nice contrast to the real world.
(Anonymous)

"slate_leeper" wrote

| How can it be modified before it is created? I have noticed this
| inconsistency before, not just on this one file.
|

Modified is the last time the file was altered.
Created is when that particular file was made,
whether or not it's a copy.

With downloads there's
an extra wrinkle: Those dates are stored as part of
the file system. They're not part of the file itself.
So preserving a date depends on a browser, ZIP
program, or whatever agent transferred the file
from another system.

If you drag a file to make a copy you should see
that the new file has a created time of just now,
but the same modified date as the original.

Try not to talk about this with Linux fanatics.
They'll begin to go bug-eyed, start spitting, then
burst forth with a sermon about how Windows
does it wrong. Apparently in the Unix world it's
traditional to define created in terms of the original
file, whenever a file is a copy.

That gets into an almost philosophical issue:
If you write a text file and eventually change all
the text in a 3rd "descendant" copy, but keep the
same name, is that the same file as the original?

Unix says a file has being and a copy is only an
extension of the original. Windows says all files are
created equal.

On 01/01/2019 15.13, Mayayana wrote:
"slate_leeper" wrote

| How can it be modified before it is created? I have noticed this
| inconsistency before, not just on this one file.
|

Modified is the last time the file was altered.
Created is when that particular file was made,
whether or not it's a copy.

With downloads there's
an extra wrinkle: Those dates are stored as part of
the file system. They're not part of the file itself.
So preserving a date depends on a browser, ZIP
program, or whatever agent transferred the file
from another system.

If you drag a file to make a copy you should see
that the new file has a created time of just now,
but the same modified date as the original.

Try not to talk about this with Linux fanatics.
They'll begin to go bug-eyed, start spitting, then
burst forth with a sermon about how Windows
does it wrong.

Not at all :-p

Apparently in the Unix world it's
traditional to define created in terms of the original
file, whenever a file is a copy.

As timestamps are not stored inside the files, but externally on the
filesystem metadata, they can change. Same as in Windows.

That gets into an almost philosophical issue:
If you write a text file and eventually change all
the text in a 3rd "descendant" copy, but keep the
same name, is that the same file as the original?

Unix says a file has being and a copy is only an
extension of the original. Windows says all files are
created equal.

Nay. It simply depends on how the programmer does his program. Think of
an editor: create new file, write the old contents plus modifications,
close it, rename the old as .bak, rename the new as .txt.

--
Cheers, Carlos.

"Carlos E.R." wrote

| Unix says a file has being and a copy is only an
| extension of the original. Windows says all files are
| created equal.
|
| Nay. It simply depends on how the programmer does his program. Think of
| an editor: create new file, write the old contents plus modifications,
| close it, rename the old as .bak, rename the new as .txt.
|

That would be a different case. It's not typical
for 3rd-party software to be setting file dates
on saved files, and a save operation wouldn't
generally be designed to maintain a particular
date pattern. Software generally just saves as
the loaded file or or saves as new. Which is why
Save and Save As are almost universally on file
menus.

But that's another issue. We're talking about how
the system treats files. A copy of a file is a new
creation on Windows. As I understand it, on Unix
or Mac a copy will have the creation date of the
original file.

Mayayana wrote:
"slate_leeper" wrote

| How can it be modified before it is created? I have noticed this
| inconsistency before, not just on this one file.
|

Modified is the last time the file was altered.
Created is when that particular file was made,
whether or not it's a copy.

With downloads there's
an extra wrinkle: Those dates are stored as part of
the file system. They're not part of the file itself.
So preserving a date depends on a browser, ZIP
program, or whatever agent transferred the file
from another system.

If you drag a file to make a copy you should see
that the new file has a created time of just now,
but the same modified date as the original.

Try not to talk about this with Linux fanatics.
They'll begin to go bug-eyed, start spitting, then
burst forth with a sermon about how Windows
does it wrong. Apparently in the Unix world it's
traditional to define created in terms of the original
file, whenever a file is a copy.

That gets into an almost philosophical issue:
If you write a text file and eventually change all
the text in a 3rd "descendant" copy, but keep the
same name, is that the same file as the original?

Unix says a file has being and a copy is only an
extension of the original. Windows says all files are
created equal.

As Carlos also mentioned, 'Unix' does no such thing. It fully depends
on the software used. For example the most basic copy command - cp(1) -
by default does *not* copy mode (rwx, etc.) ownership and timestamps.

Likewise, 'Windows' doesn't do it any fixed way either, but it also
depends on the software used.

Mayayana wrote:
"Carlos E.R." wrote

| Unix says a file has being and a copy is only an
| extension of the original. Windows says all files are
| created equal.
|
| Nay. It simply depends on how the programmer does his program. Think of
| an editor: create new file, write the old contents plus modifications,
| close it, rename the old as .bak, rename the new as .txt.
|

That would be a different case. It's not typical
for 3rd-party software to be setting file dates
on saved files, and a save operation wouldn't
generally be designed to maintain a particular
date pattern. Software generally just saves as
the loaded file or or saves as new. Which is why
Save and Save As are almost universally on file
menus.

Well, a image manipulation program might change the orientation bits
in the EXIF part of a JPEG, but decide to preserve the original
timestamps when doing a Save.

But that's another issue. We're talking about how
the system treats files. A copy of a file is a new
creation on Windows. As I understand it, on Unix
or Mac a copy will have the creation date of the
original file.

That would be a tad hard, because a Unix file does not *have* a
'creation' date! :-) It has 'Time of last status change' (ctime),
which is somewhat similar in use, but not the same. For example if you
change the mode (rwx, etc.) of a file, the ctime is changed, which would
not happen for a 'Windows' file.

"Frank Slootweg" wrote


| Well, a image manipulation program might change the orientation bits
| in the EXIF part of a JPEG, but decide to preserve the original
| timestamps when doing a Save.
|
Yes, but that's a whole other kettle o' bytes. The filetime
properties generally won't be changed by software. The
EXIF data is part of the file header and anything goes. And
there are at least 3 date/time EXIF values. It also doesn't
have to be there. There can be EXIF and/or IPTC or neither.
I generally strip all EXIF data from JPG files that I work on.
As with MS Office files, I don't like to leave in possible privacy-
intruding data that's of no value to me.

| But that's another issue. We're talking about how
| the system treats files. A copy of a file is a new
| creation on Windows. As I understand it, on Unix
| or Mac a copy will have the creation date of the
| original file.
|
| That would be a tad hard, because a Unix file does not *have* a
| 'creation' date! :-) It has 'Time of last status change' (ctime),
| which is somewhat similar in use, but not the same. For example if you
| change the mode (rwx, etc.) of a file, the ctime is changed, which would
| not happen for a 'Windows' file.

There is the newer crtime. But I don't doubt that
you know more about that than I do. I remember a debate
about this once, but I might be remembering an issue with
Macs rather than with Unix in general. As with this example:

https://superuser.com/questions/6048...from-command-l

The question describes two behaviors on Macs
that are both different from Windows.

Mayayana wrote:
"Frank Slootweg" wrote


| Well, a image manipulation program might change the orientation bits
| in the EXIF part of a JPEG, but decide to preserve the original
| timestamps when doing a Save.
|
Yes, but that's a whole other kettle o' bytes. The filetime
properties generally won't be changed by software. The
EXIF data is part of the file header and anything goes. And
there are at least 3 date/time EXIF values. It also doesn't
have to be there. There can be EXIF and/or IPTC or neither.
I generally strip all EXIF data from JPG files that I work on.
As with MS Office files, I don't like to leave in possible privacy-
intruding data that's of no value to me.

In case I wasn't clear, I meant (preserving) the timestamps *of* the
file (i.e. as recorded by the filesystem), not the timestamps *in* (the
EXIF part of) the file.

| But that's another issue. We're talking about how
| the system treats files. A copy of a file is a new
| creation on Windows. As I understand it, on Unix
| or Mac a copy will have the creation date of the
| original file.
|
| That would be a tad hard, because a Unix file does not *have* a
| 'creation' date! :-) It has 'Time of last status change' (ctime),
| which is somewhat similar in use, but not the same. For example if you
| change the mode (rwx, etc.) of a file, the ctime is changed, which would
| not happen for a 'Windows' file.

There is the newer crtime. But I don't doubt that
you know more about that than I do.

crtime - often called 'Birth' - might or might not be available,
depending on the filesystem type or/and API/command used. So one
shouldn't assume it's available all the time or even most of the time.
See for example the crtime/birthtime part of this article:

'Unix Timestamps Explained'
https://stuff-things.net/2015/06/17/unix-timestamps-explained

I remember a debate
about this once, but I might be remembering an issue with
Macs rather than with Unix in general. As with this example:

https://superuser.com/questions/6048...from-command-l

The question describes two behaviors on Macs
that are both different from Windows.

Yup. IOW, it's a mess, welcome to non-standards! :-)