File Attributes/Properties

[snowshed1]

Let me ask the question in a different way... Is "birth time" the date and time a file is written to a hard drive, or some other location?

I shall admit to having some trouble fathoming what exactly could not be immediately clear from the phrasing "creation (or birth) time". And that such is not a complaint either. Fascinating; my mind no doubt out of sheer familiarity seems to disallow me to connect synapses in any order in which such is not obvious.

The problem is your familiarity with the subject. And, you are not alone in that. I see it as a normal progression of the mind in individuals who have spent so much time and effort being involved with something, they simply forget how to view the "product" through the eyes of a "newbie".

"Creation (or birth) time"... For you to understand that phrase is a simple as getting up out of your chair, because you are familiar with LInux/Unix terms. Me? I'm not familiar with LInux/Unix phrases, so I don't know exactly what it means. And, it's normal.

I have an online friend in Scotland I regularly email with. Now, we both speak English. But I can't begin to tell you how many times I have to go to the web to figure out what he's trying to tell me. And this is no different.

Let me ask the question in a different way... Is "birth time" the date and time a file is written to a hard drive, or some other location?

If at time N but not any earlier time a given file exist on a given file system, N is the creation time of said file on said file system. The moment of a file's non-existence morphing into existence. The (time of the) poof of creation. The time the file was "enlisted" in the filesystem for the first time. The old mtime would be a modification time, a time a file's content was modified, and as such more the "time a file is written to" [ ... ] as you put it.

"'Enlisted' in the filesystem is another phrase I've never heard in my life! But, I think we've got it... When I'm finished with a document, and save it to the HD when I close the document, the birth time is when I saved the document to the HD.

[rene]

When I'm finished with a document, and save it to the HD when I close the document, the birth time is when I saved the document to the HD.

Right. OK, I guess I see where your doubts stemmed from, namely a what to me would count as not properly limited definition of "file". Specifically, an unsaved document open in an e.g. word processor is not a file; it's a document, and technically just a bit of memory under control of the word processor application. It's only upon saving the document in a file that the two concepts, "document" and "file", become related.

Admittedly, once the document is saved few would complain about using the words interchangeably, but fundamentally "a file" is defined as merely a container (i.e., for anything), or even more simply as a unit of storage in a file system. Given that definition its "creation time" becomes an obvious concept.

[snowshed1]

Hi, rene,

First thing I'd like to say is, I hope you are not feeling frustrated with my incessant questions, and feeling like your time is being wasted. It's not.

We are going in the direction of what I'm trying to learn. Think of this exercise as languages, English, French, Greek. Replace those with Linux/Unix, Windows, MacOS.

I'm working at learning the Linux/Unix terminology for things at the moment. I know the Windows and Mac names for what we are talking about.

It's like the earlier message that panel=taskbar=shelf=dock.

When I'm finished with a document, and save it to the HD when I close the document, the birth time is when I saved the document to the HD.

Right. OK, I guess I see where your doubts stemmed from, namely a what to me would count as not properly limited definition of "file". Specifically, an unsaved document open in an e.g. word processor is not a file; it's a document, and technically just a bit of memory under control of the word processor application. It's only upon saving the document in a file that the two concepts, "document" and "file", become related.

Yep. Next for me, then, is the date and time information that is associated with the file once it's on the hard drive. Which is information kept by the filesystem, and not embedded in a file. Basically focusing on Jpgs, in particular, because of my brother-in-law, which is a "whole 'nuther story"!

When I'm finished with a document, and save it to the HD when I close the document, the birth time is when I saved the document to the HD.

Admittedly, once the document is saved few would complain about using the words interchangeably, but fundamentally "a file" is defined as merely a container (i.e., for anything), or even more simply as a unit of storage in a file system. Given that definition its "creation time" becomes an obvious concept.

Agreed. "Creation time" is the date and time associated with the file by the filesystem when it is written to the HD.

Now, comes the "understanding" I'm searching for.

I take a photo with my camera, JPG001. The date and time on the camera is embedded as EXIF data. I copy the file from the SD Card from the camera to my Mint 19.0 hard drive. Via the filesystem, the file on the hard drive is given a "creation time'.

Am I good so far?

If yes, is there a way to display that creation time in any of the file managers? The media columns plug in for Nemo does not display that information. There are 2 date options in the plug in. One is labeled EXIF Date, and the other is just Date, which is blank for JPG001. No idea what that date is supposed to tell me. I'll have to go to the plugin author's site on GitHub and see what I can learn there.

I'm sure someone, somewhere, is asking, "Why do we need this information?" I honestly don't know. But, the information is available in Windows and MacOS. This indicates to me that somewhere in the distant computer past, someone saw a need for it.

[rene]

Agreed. "Creation time" is the date and time associated with the file by the filesystem when it is written to the HD.

Careful: "when it is written to the file system" as I've stressed a few times, and as is important for the current conversation in two ways.

1. The previously mentioned fact that not every type of file system support storing a creation timestamp. That historically no UNIX filesystem in fact did and for example FAT did not before Windows 95. Latter may I suppose be relevant for camera's if they use some type of "basic" FAT for an SD card. I do not myself know what's common there; am not a camera person.

2. The fact that if you copy a file containing a photo from your camera's SD card to an ext4 file system, that is the time that file is created on the ext4 file system. That the creation timestamp we are here talking about would be the time it was copied. For the historic UNIX timestamps I would've needed to classify that with "unless you specifically arrange otherwise" but with the lack of btime support in the usual tools, in this case not really even that.

Given that second point I do wonder if you really wanted to ask the question you ended up asking but... yes, in fact. Cinnamon's default file manager Nemo can since a few versions display btime on file systems that supports that timestamp, and do so without any extension: https://github.com/linuxmint/nemo/commi ... 988e888a2c. The column names are "Date Created" and "Created - Time". Why not either "Date Created" and "Time Created" or "Created - Date" and "Created - Time" you ask? I was told there is actually a very good reason for this but just when the developer was about to tell me he tripped over the empty bottles of scotch on the floor, fell and passed out.

The "Date" and "EXIF Date" columns are indeed extension fields from the plug-in: https://github.com/linuxmint/nemo-exten ... columns.py. Latter would be obvious, former would appear to be a field filled in from a for example supported audio file date tag.

As per all of the above I would expect that your main interest lies with the "EXIF Date" field as a photo creation time but if you were in fact interested in the file creation time as you ended up asking, yes, Nemo as part of Mint 19.1 on e.g. ext4 can show this.

[gm10]

I'm sure someone, somewhere, is asking, "Why do we need this information?" I honestly don't know. But, the information is available in Windows and MacOS. This indicates to me that somewhere in the distant computer past, someone saw a need for it.

Indeed. There is little value to that information. The modification time is what matters.

Also to possibly add to your terminology confusion or maybe clear it up a little more: As rene keeps stressing, the creation time is the time the file got created on the file system, not the time the file got created in memory. A very easy to understand and replicate example: Press your PrtScr button to take a screenshot. Wait a minute, then press the button to save the file. Now the creation time is the time you pressed the button to save, but the modification time is the time you took the screenshot. In other words, modification time will be earlier than the creation time. Disclaimer: This may not actually apply to Xfce's screenshot tool, I'm not familiar with what Xfce uses.

[snowshed1]

I'm sure someone, somewhere, is asking, "Why do we need this information?" I honestly don't know. But, the information is available in Windows and MacOS. This indicates to me that somewhere in the distant computer past, someone saw a need for it.

Indeed. There is little value to that information. The modification time is what matters.

I have never had a flash of brilliance and said "That's why they created it!" My only thought is, there were some people that are/were business or some such oriented that had a need for this information. If it were truly inconsequential, why did both MS and Apple add to their OS?

Also to possibly add to your terminology confusion or maybe clear it up a little more: As rene keeps stressing, the creation time is the time the file got created on the file system, not the time the file got created in memory.

On this particular term, got it under control! Just a couple hundred more to go! ROFL

I'd like to get to the point where I really feel comfortable mentioning Linux as an option to Windows and Macs, but I need to know more things like this, just in case a Windows user asks me "How do I display Date Created in Linux?" As of yet, I don't know if there is a way to show it, the media dates plugin for Nemo doesn't show that time.

FWIW, I think a lot of Windows users, when they see Date Created when a photo is highlighted in Windows/File Explorer, they think that is the date the photo was taken.

A very easy to understand and replicate example: Press your PrtScr button to take a screenshot. Wait a minute, then press the button to save the file. Now the creation time is the time you pressed the button to save, but the modification time is the time you took the screenshot. In other words, modification time will be earlier than the creation time. Disclaimer: This may not actually apply to Xfce's screenshot tool, I'm not familiar with what Xfce uses.

There's one other way to have the modification time be earlier than the creation time. A bad CMOS battery. This was happening to me while trying to figure this out, because the motherboard would remember the date, but not the time. Every time I turned the computer off, the motherboard wouid default back to 00:00:00, but the date would be correct. New battery, no problem.

[snowshed1]

Agreed. "Creation time" is the date and time associated with the file by the filesystem when it is written to the HD.

Careful: "when it is written to the file system" as I've stressed a few times, and as is important for the current conversation in two ways.

1. The previously mentioned fact that not every type of file system support storing a creation timestamp. That historically no UNIX filesystem in fact did and for example FAT did not before Windows 95. Latter may I suppose be relevant for camera's if they use some type of "basic" FAT for an SD card. I do not myself know what's common there; am not a camera person.

AIUI, support for this started with ext4, correct? Also, SD cards and thumb drives are formatted with exFAT, which I find I now need to sort through at some point. https://en.wikipedia.org/wiki/ExFAT

I'm neither a camera nor a music person to this depth. Which is why my camera is point and shoot, and I do nothing with programs like Audacity or making videos.

But this quest has been an eye opener for how much data is out there and available to a user if they know of it, and how to use it. For Windows, there's a photoviewing program called Irfanview. When you look at the EXIF data of a photo in that program, there must be 25 items in the list.

Agreed. "Creation time" is the date and time associated with the file by the filesystem when it is written to the HD.

2. The fact that if you copy a file containing a photo from your camera's SD card to an ext4 file system, that is the time that file is created on the ext4 file system. That the creation timestamp we are here talking about would be the time it was copied. For the historic UNIX timestamps I would've needed to classify that with "unless you specifically arrange otherwise" but with the lack of btime support in the usual tools, in this case not really even that.

If I have this all sorted correctly, and I copy the file from the SD card to Windows, it will be listed as Date Created. On the Mac, just Created.

Agreed. "Creation time" is the date and time associated with the file by the filesystem when it is written to the HD.

Given that second point I do wonder if you really wanted to ask the question you ended up asking but... yes, in fact. Cinnamon's default file manager Nemo can since a few versions display btime on file systems that supports that timestamp, and do so without any extension: https://github.com/linuxmint/nemo/commi ... 988e888a2c. The column names are "Date Created" and "Created - Time".

Yes sir, I did intend to ask the question. I want to see what other file managers can do in this regard, but at this point, I'd prefer Nemo over Thunar because of the media columns. I've got a specific feature I'd like to find in a Linux file manager, but that's a subject for another thread.

Why not either "Date Created" and "Time Created" or "Created - Date" and "Created - Time" you ask? I was told there is actually a very good reason for this but just when the developer was about to tell me he tripped over the empty bottles of scotch on the floor, fell and passed out.

ROFL!!

The "Date" and "EXIF Date" columns are indeed extension fields from the plug-in: https://github.com/linuxmint/nemo-exten ... columns.py. Latter would be obvious, former would appear to be a field filled in from a for example supported audio file date tag.

As per all of the above I would expect that your main interest lies with the "EXIF Date" field as a photo creation time but if you were in fact interested in the file creation time as you ended up asking, yes, Nemo as part of Mint 19.1 on e.g. ext4 can show this.

In fact, I was interested in both pieces of information.

When I get there, I'm going to request of the author he/she put where the info is taken, for all the fields. The site says audio, PDF, and photo data, IIRC. I learned audio files also have EXIF data, so if the data displayed could somehow indicate what type of file the information is from, that would be a real plus. As you can see in my screenshot, Apple gives you a short definition of all the fields. With that information, you can scroll through the possible information, and know if the information your looking for.

[rene]

AIUI, support for this started with ext4, correct?

Within the extN family of file systems, yes. Although certainly said family can be considered the native Linux file system type one of Linux's foremost features is support for many filesystem types though, and in theory any file system that supports btime on-disk would be free to expose it to higher levels now that statx support is in place in the kernel proper. I wouldn't be terribly surprised if a file system such as Btrfs or XFS was in fact quicker to the party than ext4.

There's a nice overview of file systems and their support for creation time at https://en.wikipedia.org/wiki/Compariso ... s#Metadata. It can be seen that it's basically only old UNIX file systems that don't -- but I also wouldn't be surprised if even on the in Linux supported subset of the list that does, the Linux implementation does not (yet) support btime due to this all being a fairly current development.

exFAT supports creation timestamps natively; there's exFAT implementation issues in Linux due to Microsoft-held patents and I wouldn't be able to tell you if support is present in exFAT code available on Linux. As mentioned before, basically nothing's ready for btime at the user level anyway, so how practically important any of this currently is is debatable.

For Windows, there's a photoviewing program called Irfanview. When you look at the EXIF data of a photo in that program, there must be 25 items in the list.

Not nicely integrated, but after apt install exif you'll be able to view the same information through exif -l foo.jpg.

When I get there, I'm going to request of the author he/she put where the info is taken, for all the fields. The site says audio, PDF, and photo data, IIRC. I learned audio files also have EXIF data, so if the data displayed could somehow indicate what type of file the information is from, that would be a real plus.

Audio files don't have EXIF data no (an image file metadata format) but do generally support metadata, in their context referred to as "tags". Not only is said metadata not EXIF though, it's in an for any specific audio file format specific metadata format. E.g. MP3 stores tags quite differently from FLAC. The latter sharing a format with Ogg is about the only consistency in all of it.

This to say that I'd doubt you'd have much success with your request: A file manager plug-in such as the one for Nemo relies on an to it external library which in turn cobbles together some unspecified number of formats it knows about generally through to those formats specific libraries, mapping their native formats to some least common denominator metadata format to present to the plug-in. The plug-in itself would not generally have any specific idea about where said metadata came from other than "from that nifty library I'm calling into!".

Yes, it's a mess. As is the default situation for most anything on Linux as you will learn when you spend more time with it.

[snowshed1]

AIUI, support for this started with ext4, correct?

Within the extN family of file systems, yes. Although certainly said family can be considered the native Linux file system type one of Linux's foremost features is support for many filesystem types\

I realized this when I first heard of GParted, and took a look at it.

There's a nice overview of file systems and their support for creation time at https://en.wikipedia.org/wiki/Compariso ... s#Metadata.

That's more information there than I'll ever digest!

For Windows, there's a photoviewing program called Irfanview. When you look at the EXIF data of a photo in that program, there must be 25 items in the list.

Not nicely integrated, but after apt install exif you'll be able to view the same information through exif -l foo.jpg.

Yep, it's hard to find, but at least you have access to that much information. I'm not a pro photograher, but it sure looks comprehensive enough for me. LOL At the opposite end of the spectrum is Exif Tool, and it totally above my head. It's more than what I'm looking for.

When I get there, I'm going to request of the author he/she put where the info is taken, for all the fields. The site says audio, PDF, and photo data, IIRC. I learned audio files also have EXIF data, so if the data displayed could somehow indicate what type of file the information is from, that would be a real plus.

Audio files don't have EXIF data no (an image file metadata format) but do generally support metadata, in their context referred to as "tags".

This Wikipedia article, https://en.wikipedia.org/wiki/Exif, disagrees with that. But we may be wandering into the area of semantics.

This to say that I'd doubt you'd have much success with your request:

True, but as George Bernard Shaw said, "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." If you would like to see some kind of change, to anything, you have to ask.

I think we've covered everything I was after, and more, at this point.

Just one last question, for Linux terms like btime, etc., is there a simplified list of them with their definitions? A list something like the one in the screenshot in my original post. I don't want to know how to use them in program code, just what they are, and what they mean/do/represent.

[rene]

This Wikipedia article, https://en.wikipedia.org/wiki/Exif, disagrees with that. But we may be wandering into the area of semantics.

Wouldn't say so, no. I was simply unaware of any such thing as an "EXIF audio file specification". My bad.

Just one last question, for Linux terms like btime, etc., is there a simplified list of them with their definitions? A list something like the one in the screenshot in my original post.

Not really as in your OP no; the fields listed there exist (mostly) at the level of format-specific metadata/tags and need to as such be gleaned from format-specific documentation. Or worse; in for example the specific case of Ogg Vorbis / FLAC tags really hardly any standard exists at all. I.e., there's a list of few standard tags here: https://www.xiph.org/vorbis/doc/v-comment.html but compare with e.g. https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping to get an idea of how many more are in use in the wild. Had to recently in fact sort through some of that to obtain a by mediaplayers somewhat widely supported but still expansive enough subset.

As to the more standard OS-level metadata I'd primarily point to man stat for what's available.

Sorry; already said it was a mess...

[snowshed1]

Just one last question, for Linux terms like btime, etc., is there a simplified list of them with their definitions? A list something like the one in the screenshot in my original post.

Not really as in your OP no; the fields listed there exist (mostly) at the level of format-specific metadata/tags and need to as such be gleaned from format-specific documentation. Or worse; in for example the specific case of Ogg Vorbis / FLAC tags really hardly any standard exists at all. I.e., there's a list of few standard tags here: https://www.xiph.org/vorbis/doc/v-comment.html but compare with e.g. https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping to get an idea of how many more are in use in the wild. Had to recently in fact sort through some of that to obtain a by mediaplayers somewhat widely supported but still expansive enough subset.

As to the more standard OS-level metadata I'd primarily point to man stat for what's available.

Sorry; already said it was a mess...

Hi, rene,

Sorry for the late reply, I somehow missed this message.

I'll check those links, and them move on.

[snowshed1]

This is a thanks to everyone who posted help and suggestions to my question.