If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
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) |
Ads |
#2
|
|||
|
|||
file modified/created dates
"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. |
#3
|
|||
|
|||
file modified/created dates
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. |
#4
|
|||
|
|||
file modified/created dates
"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. |
#5
|
|||
|
|||
file modified/created dates
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. |
#6
|
|||
|
|||
file modified/created dates
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. |
#7
|
|||
|
|||
file modified/created dates
"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. |
#8
|
|||
|
|||
file modified/created dates
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! :-) |
Thread Tools | |
Display Modes | Rate This Thread |
|
|