OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Setup & Installation => Topic started by: Dariusz Piatkowski on September 12, 2020, 02:22:57 am
-
Hmm...seems like this should be easy to do, and yet no hits so far as to what the answer is.
I have a JFS IFS here, DIR at CLI shows me the 'last write' date instead of 'creation date'. There is also the 'last access' date that's available.
Now, I spent years using HPFS386 and for the life of me can't ever recall having this issue, so I suspect something about JFS is different.
I have 'SET DIRCMD=/v' defined in CONFIG.SYS, but I am thinking this should not have an impact here as that only puts the byte counts into human-friendly format.
Is there a DIR option (or some system-wide config perhaps) that would allow me to force a choice of the date which should be reported?
To be honest when I'm physically at the CLI window it is because I want to see some of the details and from that perspective I care much more about the 'create date' than anything else.
Thanks!
-Dariusz
-
Good question. What you want is the birth time. There is ctime which is treated differently on Windows and Unix, see https://en.wikipedia.org/wiki/MAC_times#Change_time_and_creation_time_%28ctime%29 (https://en.wikipedia.org/wiki/MAC_times#Change_time_and_creation_time_%28ctime%29). Not sure how JFS handles ctime. Some *nix file systems do keep birth time, so we see on HPFS,
[W:\]stat STARTUP.CMD
File: STARTUP.CMD
Size: 566 Blocks: 2 IO Block: 49152 regular file
Device: 5657h/22103d Inode: 10348673449899344201 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-10 22:47:06.000000000 -0700
Modify: 2020-07-28 07:14:56.000000000 -0700
Change: 2020-07-28 07:14:56.000000000 -0700
Birth: 2019-03-20 18:07:50.000000000 -0700
[W:\]ls -lc STARTUP.CMD
-rw-r--r-- 1 root root 566 Jul 28 07:14 STARTUP.CMD
whereas on JFS,
D:\>stat STARTUP.CMD
File: STARTUP.CMD
Size: 530 Blocks: 8 IO Block: 49152 regular file
Device: 5644h/22084d Inode: 474291546461390082 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-03 05:09:32.000000000 -0700
Modify: 2019-02-11 13:04:20.000000000 -0800
Change: 2019-02-11 13:04:20.000000000 -0800
Birth: 2019-02-11 13:04:20.000000000 -0800
D:\>ls -lc STARTUP.CMD
-rw-r--r-- 1 root root 530 Feb 11 2019 STARTUP.CMD
I guess some experimentation is needed but you will likely need *nix tools to get all the time stamps from JFS.
Also there's "ls -l" (modified), "ls -la" (access) and "ls -lc" (supposed to be changed, like permissions, but not sure on OS/2, see above)
Let us know.
-
On a 4OS2 command line you can use the /t switch:
/t:w last date/time written
/t:c date/time created
/t:a last date/time accessed (read)
the default OS/2 command line does not support this switch.
-
Testing, it seems that JFS uses (*nix) c as changed rather then created. Created a file with touch and did some tests,
K:\tmp>stat test
File: test
Size: 0 Blocks: 0 IO Block: 49152 regular empty file
Device: 564bh/22091d Inode: 14461902377750889908 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-12 08:24:44.000000000 -0700
Modify: 2020-09-12 08:24:44.000000000 -0700
Change: 2020-09-12 08:24:44.000000000 -0700
Birth: 2020-09-12 08:24:44.000000000 -0700
K:\tmp>echo test >> test
K:\tmp>stat test
File: test
Size: 6 Blocks: 8 IO Block: 49152 regular file
Device: 564bh/22091d Inode: 14461902377750889908 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-12 08:24:44.000000000 -0700
Modify: 2020-09-12 08:27:52.000000000 -0700
Change: 2020-09-12 08:27:52.000000000 -0700
Birth: 2020-09-12 08:24:44.000000000 -0700
K:\tmp>cat test
test
K:\tmp>stat test
File: test
Size: 6 Blocks: 8 IO Block: 49152 regular file
Device: 564bh/22091d Inode: 14461902377750889908 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-12 08:30:16.000000000 -0700
Modify: 2020-09-12 08:27:52.000000000 -0700
Change: 2020-09-12 08:27:52.000000000 -0700
Birth: 2020-09-12 08:24:44.000000000 -0700
K:\tmp>chmod +x test
K:\tmp>stat test
File: test
Size: 6 Blocks: 8 IO Block: 49152 regular file
Device: 564bh/22091d Inode: 14461902377750889908 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-12 08:30:16.000000000 -0700
Modify: 2020-09-12 08:27:52.000000000 -0700
Change: 2020-09-12 08:27:52.000000000 -0700
Birth: 2020-09-12 08:24:44.000000000 -0700
4OS2 does seem to report the birth time though,
{0}[k:\tmp] dir /t:c test
Volume in drive K is RPM Serial number is 57BF:35BF
Directory of K:\tmp\test
9-12-20 8:24 6 124 test
6 bytes in 1 file and 0 dirs
with cmd's dir reporting modified it seems
9-12-20 8:27a 6 124 a--- test
1 file(s) 6 bytes used
And change not doing anything besides reflecting modified on OS/2, I'd guess it would on Linux or AIX where actual permissions are changed rather then EA's.
-
Strange. If I use DosQueryPathInfo, 4OS/2, OS/2 tools or the WPS, I always get the correct dates and times. All 4OS/2 (version 3.08.3-shl) options that Lars mentioned, work here. I checked this for both bootable and non-bootable JFS.
From bsedos.h:
typedef struct _FILESTATUS3 /* fsts3 */
{
FDATE fdateCreation;
FTIME ftimeCreation;
FDATE fdateLastAccess;
FTIME ftimeLastAccess;
FDATE fdateLastWrite;
FTIME ftimeLastWrite;
ULONG cbFile;
ULONG cbFileAlloc;
ULONG attrFile;
} FILESTATUS3;
typedef FILESTATUS3 *PFILESTATUS3;
That shows that the used terms on OS/2 are LastWrite, LastAccess and Creation. The WPS uses
'last write', 'last access' and 'creation'.
-
Testing, it seems that JFS uses (*nix) c as changed rather then created. Created a file with touch and did some tests,
K:\tmp>stat test
File: test
Size: 0 Blocks: 0 IO Block: 49152 regular empty file
Device: 564bh/22091d Inode: 14461902377750889908 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-12 08:24:44.000000000 -0700
Modify: 2020-09-12 08:24:44.000000000 -0700
Change: 2020-09-12 08:24:44.000000000 -0700
Birth: 2020-09-12 08:24:44.000000000 -0700
K:\tmp>echo test >> test
K:\tmp>stat test
File: test
Size: 6 Blocks: 8 IO Block: 49152 regular file
Device: 564bh/22091d Inode: 14461902377750889908 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-12 08:24:44.000000000 -0700
Modify: 2020-09-12 08:27:52.000000000 -0700
Change: 2020-09-12 08:27:52.000000000 -0700
Birth: 2020-09-12 08:24:44.000000000 -0700
K:\tmp>cat test
test
K:\tmp>stat test
File: test
Size: 6 Blocks: 8 IO Block: 49152 regular file
Device: 564bh/22091d Inode: 14461902377750889908 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-12 08:30:16.000000000 -0700
Modify: 2020-09-12 08:27:52.000000000 -0700
Change: 2020-09-12 08:27:52.000000000 -0700
Birth: 2020-09-12 08:24:44.000000000 -0700
K:\tmp>chmod +x test
K:\tmp>stat test
File: test
Size: 6 Blocks: 8 IO Block: 49152 regular file
Device: 564bh/22091d Inode: 14461902377750889908 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-09-12 08:30:16.000000000 -0700
Modify: 2020-09-12 08:27:52.000000000 -0700
Change: 2020-09-12 08:27:52.000000000 -0700
Birth: 2020-09-12 08:24:44.000000000 -0700
4OS2 does seem to report the birth time though,
{0}[k:\tmp] dir /t:c test
Volume in drive K is RPM Serial number is 57BF:35BF
Directory of K:\tmp\test
9-12-20 8:24 6 124 test
6 bytes in 1 file and 0 dirs
with cmd's dir reporting modified it seems
9-12-20 8:27a 6 124 a--- test
1 file(s) 6 bytes used
And change not doing anything besides reflecting modified on OS/2, I'd guess it would on Linux or AIX where actual permissions are changed rather then EA's.
I don't understand what you are trying to say. An OS/2 IFS only knows about creation, last write and last access,that is defined in the IFS spec. 4OS/2 allows DIR to select what date of those to display and the OS/2 DIR does not (it shows last write as it seems).
It's that simple. And your tests seem to prove just that.
-
Mostly whether JFS actually supported creation time, which many *nix filesystems don't and treat c differently. The IFS itself can only read whatever metadata the file system saves so the ext2 IFS for example may not be able to return the creation time as ext2's support for it is questionable.
-
Dave,
Yeah, I took a look at the unix stat to see what it shows and indeed it does retrieve the information I'm looking for.
However, I would much rather have DIR go after that birth/create date as opposed to having to rely on stat.
Indeed, looking into this further I found the following succint summary: "...POSIX standard only defines three distinct timestamps to be stored for each file: the time of last data access, the time of last data modification, and the time the file status last changed...".
In our case, using the specific folder example, I see the following (see attachment).
...and the matching stat on 'doc' returns:
[G:\usr\share]stat doc
File: doc
Size: 0 Blocks: 32 IO Block: 49152 directory
Device: 5647h/22087d Inode: 17446411450310105587 Links: 1
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-03-27 08:28:00.000000000 -0400
Modify: 2020-09-11 22:01:36.000000000 -0400
Change: 2020-09-11 22:01:36.000000000 -0400
Birth: 2017-11-11 23:09:14.000000000 -0500
So basically our WPS 'last write' is the unix modify & change, unless the specific case is more detailed like what you showed where there is a real distinction between Modify and Change.
Alright, so given that our very own 'DIR' is a bit of a dead-end I crafted the following stat command instead:
'stat -c "%.16w %15F %10s %n" *'
which produces the following output:
2020-08-21 11:56 regular file 8909 g:\tmp\uniaud
2005-03-27 14:14 regular file 221407 g:\tmp\unzip32.dll
2020-04-04 21:09 directory 0 g:\tmp\vslick
2014-08-02 10:22 regular file 12838045 g:\tmp\warsaw-pact.pdf
2017-09-21 10:52 regular file 6279 g:\tmp\whois_new
2017-09-21 10:52 regular file 6279 g:\tmp\whois_old
2018-08-25 18:20 directory 0 g:\tmp\Youtube
2018-08-25 18:20 directory 0 g:\tmp\yum_rpm
2020-03-13 10:46 regular file 1082760 g:\tmp\[MS-RDPEMT].pdf
2011-01-23 22:06 regular file 25187216 g:\tmp\~FFJOIN.avi
2011-01-03 23:37 regular file 7534 g:\tmp\~ffmpeg-1.log
2017-06-13 17:31 regular file 4436 g:\tmp\~ffmpeg.P1-0.log
This is good enough. I'll simply define an ALIAS for DIRC to point to stat instead and run with that, actually several ALIASes to show the: create, last access and last modify dates.
-
Mostly whether JFS actually supported creation time, which many *nix filesystems don't and treat c differently. The IFS itself can only read whatever metadata the file system saves so the ext2 IFS for example may not be able to return the creation time as ext2's support for it is questionable.
The IFS is the filesystem plus the functionality that OS/2 expects from an IFS.
It is the IFS job to properly return a creation date if the OS asks for it no matter where it gets that from. The IFS has a standardized interface, if a core filesystem does not support something (on porting a filesystem,for example) then the IFS will have to fill the gap.
The only problem is that sometimes things are not unambiguously defined: if you open a file for the very first time but it has not yet been saved to disk, is it then already created or not?
-
...This is good enough. I'll simply define an ALIAS for DIRC to point to stat instead and run with that, actually several ALIASes to show the: create, last access and last modify dates.
Ahh...and then I remembered: our CMD does not allow you to define an ALIAS!!! ???
So, a quick REXX script build and I've got me the three flavours of DIR command. I've attached these if anyone needs this, the only pre-requisite is that you must of course have the stat.exe utility.
Thanks for the feedback everyone!
-
Can't you just use the 4OS/2 commandline ? That supports everything you want right out of the box.
-
Can't you just use the 4OS/2 commandline ? That supports everything you want right out of the box.
Sure could I believe, but I do not have it installed, nor do I want to toss yet another CLI shell on top of the stuff that's already part of the YUM/RPM installs.