MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » May 2014

RE: IFS file Created, Accessed and Changed info



fixed

Thanks Jon, very helpful!

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilson Jonathan
Sent: Thursday, May 29, 2014 9:14 AM
To: Midrange Systems Technical Discussion
Subject: 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


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






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact