× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



John,

There's a system call named "stat" on both Unix and Windows, that
retrieves three times. "Access" time and "content modification"
time have the same meaning on both systems,

That's interesting to me because it's a significant difference between
what I see on iSeries where "Access" time and "content modification"/
"Changed" time values seem to be handled in a more logical or "correct"
way ?

I'm not yet clear on "Accessed" and "Changed" because I not sure if these
values are "inherited" from the remote system, or if they are "re-set"
as they are "received", but I believe the values start with those from
the source system and remain until changed on the receiving or iSeries.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Yeung
Sent: Thursday, May 29, 2014 10:11 AM
To: Midrange Systems Technical Discussion
Subject: Re: IFS file Created, Accessed and Changed info

On Thu, May 29, 2014 at 11:13 AM, Wilson Jonathan <piercing_male@xxxxxxxxxxx> wrote:

http://www.techrepublic.com/article/build-your-skills-learn-to-manipul
ate-file-time-stamps-in-windows/

Gives a fairly good over view of windows time stamps (noteable is the
"resolution" of changed time is quite large)

Well, what the article (which is over 10 years old) actually says is that the resolution varies among the different possible times you're looking at:

"The major difference is in the resolution time, which can vary from
10 milliseconds for "create time" on FAT-formatted files to one hour for 'access time' on NTFS-formatted files."

This is an amazingly awkward and uninformative statement. What about the "access time" on FAT or the "create time" on NTFS, or the "change time" on either? In any case, the one hour seems kind of preposterous. Even the screen shots in that very article strongly suggest that the access time has resolution no worse than one second.

I think the resolution on all three times are the same for any given filesystem. I could be wrong, but it just seems like a ridiculous idea to make some timestamps have finer resolution than others.

I seem to recall some strange differences between unix, linux, and
windows

There are all kinds of differences. Some subtle, some less so.

There might also be oddities depending on how the files were
created/modified, etc. on the win machine...

The oddities are dependent not just on the Windows machine. You can change timestamps on any machine, any platform. Windows, Unix, Linux, IBM i, you name it. So there is always a chance that the timestamp isn't "historically accurate" by any definition of "history" and "accuracy".

It's like they teach you in driver's ed about cars and turn signals:
When you see a car approaching an intersection and its right turn signal is on, what does that tell you? Answer: That the right turn signal is on. Period.

(I think Linux is even more problimatic as its concept of
"changed/created" as denoted in the FS is different to "birth time"
and ISTR changed means "attribute/node" change time not data changed
time.)

There's a system call named "stat" on both Unix and Windows, that retrieves three times. "Access" time and "content modification" time have the same meaning on both systems, but the third time is "creation" time on Windows and "metadata change" time on Unix.

I personally would process the files differently... ignore the times,

Very sound advice!

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.