In a directory I have 2 files, which are modified at the same time.
One is displayed with the data Aug 13 12:15 and the other one Aug 13 2018. As far as I know, the ls -l command displays a time when the file is less than a year old. And a year when it is older.

Now the files are a result of storing an mplayer stream. Two files, so two mplayer streams, which are identical except for the URL they are playing.

There is a script running which monitors the file growth. Every 20 seconds or so the script checks the increase in file size. If this is satisfactory, the file is renamed. The second number in the file name is updated to the current time stamp.

Mplayer does not care about the changed file name. Internally mplayer uses a file handle, not the file name.

I have seen more often that both files being written had a time stamp displayed as Aug 13 2018. But all files which were not written anymore, just renamed one last time had a time stamp Aug 13 12:24. Or whatever the last modification date was.

But I just don't understand why 2 files being appended at the same time, and being renamed every 20 seconds have a different time stamp display each.

jlinkels

Curious...

Perhaps only the file still being updated doesn't have the hh:mm part?

Do all files which have had the last rename have the hh:mm part?

Edit: Perhaps related...
I was testing my printer connectivity to this Desktop by printing a page from SciTE. The page was unsaved...that is, there was no file.
At the top of printout, the actual date and time was printed: 8/03/2015 09:06:35 AM
At the bottom, the line: "File date: 12/31/1969 File time: 05:00:00 PM"
That appears to be the day before the Unix epoch date (not sure why the 5PM time, tho), which makes me think the time stamp might be "in process" if there is no file (or if the file is being updated)

As it seems, if the file rename is the last action, the Aug 13 20:23 is displayed. If the append is the last action the Aug 13 2018 is displayed.

Obviously, during appending usually the append action is last. What I saw was a hit by chance. On one file the directory was displayed after file rename and before the next append.

While the files are still being appended the Aug 13 2018 is displayed. Once appending has stopped and the last rename has happened the display is Aug 13 20:23.

The difference is of course that in one case the file changes (appending) in the other case the directory entry (file name) changes.

It is not that there is no time stamp or the date is set to the epoch at some moment. The time stamp seems OK, but the displayed format is off.

It still doesn't make sense. The display function should check if the last modification time is unambiguously less than a year ago. Regardless whether the file contents has changed. I am sure I miss some knowledge to understand this.

jlinkels

It also displays only date when the timestamp is future, as can happen through an errant or intended difference in UTC offset amongst different source filesystems and local filesystem(s).

1 members found this post helpful.

The recording process runs on a server. I can access the directory on the server and from a client over NFS.

The server and client both are set to UTC. The client is even time-synced to the server. So there can be no time difference, no time zone offset.

I just wanted to check if there was any difference between display when the directory is listed in the server shell or on the client over NFS. But today everything shows with the time, excluding the year. So Aug 15 16:05. Sigh.

jlinkels

BTW, the hh:mm part of the display is replaced with the year if the file is more than six months old, not one year.