Re: IFS file Created, Accessed and Changed info

On Thu, 2014-05-29 at 13:40 +0000, Gary Thompson wrote:

I am investigating a problem with a custom app designed to
to read text files transferred to our iSeries IFS from another
"win-tel" server on our network.

The custom app has a problem where about 1% of the files received
are not completely processed and knowing what the different Created,
Accessed and Changed values represent will help my analysis.

Is "Created" set by the iSeries at the time the file is copied to the IFS ?

Or, is "Created" an attribute preserved from the system where the file
was first created ?

Same question for "Changed"; is this an attribute preserved from the
system which created and then updated the file ?

The current method used by the "win-tel" server uses robocopy to
copy these text files to a "mapped drive" on our iSeries, and it would
help explain the difference I see between the Created, Changed and
Accessed info.

Note: I changed Accessed by using EDTF to open and then close one
file, but without changing file data in any way, and I changed Accessed
again by using DSPF. The value of Changed for this file was not altered
by either EDTF or DSPF.

http://www.techrepublic.com/article/build-your-skills-learn-to-manipulate-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)

I seem to recall some strange differences between unix, linux, and
windows when copying or moving files between differing "disks" and/or
systems and I would guess this problem might be magnified depending on
how the "shared drive" is shared (via samba or a/n-other).

There might also be oddities depending on how the files were
created/modified, etc. on the win machine... ie its all done directly
from the given win machine, or some remote computer is accessing the win
machine's files and/or changing the dates/times manually or using a
machine local time and not the servers times.

(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.)

I personally would process the files differently... ignore the times,
and instead "move" a file once processed, or as the first stage of the
process, (and/or change its time on the I via the I) from a holding
folder, to a processed folder or rename the file to a "I've done this
one" naming structure. (my fave way was to rename files from ".txt" to
".txt.processing" and finally ".txt.done" which meant they were self
documenting which was a godsend if something broke)

One obvious problem would be if multiple jobs might process the file(s)
and need some kind of "I'm doing this one, so you can't" kind of "locks"
for wont of a better term, although the same problem holds true if using
date/time changes.

Jon