All directories extracted have the datestamp of the directory, as the current date and time that it was extracted. (LhA xad client, 69264 bytes 7th Feb 11)
I at least use standalone lha for lha files - except the ones with unsupported compression type - and xad typically for zip files (I bet you know why).
It works properly here. I created an lha archive of a directory (with files) with Amiga lha 2.15 and extracted it with XAD lha (some one you have) and the dates were preserved properly. Have you tested multiple archives? You may have gotten one of those bogus Linux produced lha files.
EDIT: I misunderstood what you were saying. I thought that you meant the files in a directory had new dates. You are right, the directory date is changed to the current date. As others have pointed out, this may be an issue related to changes in the way the OS works.
I'll retest it soon. Thing is, in Dopus4, double clicking the .lha to view it as a directory showed the correct datestamp, but extracting it in Dopus or UnArc, all the directory datestamps/timestamps were at the exact time of extraction.
The .lha is one of my own recent libraries I uploaded to OS4Depot. Any of them.
All the datestamps and timestamps for the files themselves are correct. I am extracting to RAM:
Re-tested it. Same issue. Doesn't matter if it's extracted to RAM: or the Hard Disk Drive, or if the .lha was from years ago or now.
If you are using the XAD LhA client from Chris (7th Feb 2011, 69264 bytes, in libs:xad/), then the directories it extracts will have the current date and time, instead of the date and time the archive was made. Tested with both Dopus4 and UnArc.
Please confirm? Someone else?
LhA in libs:xad/ is v1.16. md5 starts with "3fd032". I know it's in use because without it I had the Y2K11 issue.
Hmm, even if I use c:lha, it does the same thing. I'm going to have to investigate some more.
Edit:
OK, well, with all archives, for example .tar.gz. If the directory has something in it, then because it extracts the files after creating the directories, the filesystem will update the time/datestamp of the directory anytime something inside it is modified.
I could swear it wasn't this way before. Am I going mad? :)
It's nothing new and the reason for it is quite simple actually: When the archiver extracts the files, it writes to these directories and consequently their timestamp gets updated by the file system (at least in the case of FFS, not sure about the others).
If a drawer is empty, it will retain its original timestamp when it is extracted.
Yeah. I see the logic behind it, I just thought I remembered seeing everything get extracted with all the original timestamps and datestamps, prior to fiddling around inside the directories after extracting.
So I guess I just never noticed before. 20 years of not noticing :-/
So I guess I just never noticed before. 20 years of not noticing :-/
Not necessarily. In OS4.1 (if not earlier) they change the behaviour of date stamps on folders:
Before that AmigaOS only updated the date stamp for changes immediately inside the folder. i.e. Changing the file given by the path "Volume:One/Two/Three/File" would only change the date stamp of folder "Three".
But after that AmigaOS (at least for some filing systems) updates the date stamp OF ALL CONTAINING FOLDERS all the way. i.e. Changing the file given by the path "Volume:One/Two/Three/File" would change the date stamp of folders "Three", "Two" AND "One".
If XAD/LhA were written with the former folder behaviour in mind, then they **might** have set the folder date after extracting all the files in the immediate folder. That would have avoided new files causing the folder's date to change. But with the newer folder behaviour, this "work-around" would no longer work reliably.
@ChrisH Apparently, OS4 XadMaster and OS4 lha program need to be updated to account for this new OS4 behavior. It can be done because I can do it with Dopus4. If I double-click an lha archive in a Dopus4 lister, the archive contents are displayed in the lister with correct (original) dates for directories. Copying the displayed archive files to another location (like ram:) preserves the original dates. Probably XadMaster & lha need to reset the directory dates from the bottom up after extracting the archive.
@MickJT Wow. I tried you procedure and got different results. The date of the AmiVNC4 directory changed to 12-Mar-08 instead of back to the original 09. It makes no sense to me either. However, if you list the archive with "lha v archive.lha" you will notice that no seperate directory date is shown. The directory date that Dopus4 shows is always the date of one of the files in the directory. Maybe the directory date itself is not saved in the archive.
create a test directory, cd to it create several directories within it, add a few file at the top level, put files in some but not all of the sub directories.
cd to the top level and recursvely archive the directory, what do you see?
9.RAM Disk:> list test all
Directory "test" on Friday 20-May-11
biing Dir ----rwed Today 02:48:12
bash Dir ----rwed Today 02:47:58
bar 4 ----rwed Today 02:45:16
1 file - 4 bytes - 2 directories - 6 blocks used
Directory "test/biing" is empty
Directory "test/bash" on Friday 20-May-11
foo empty ----rwed Today 02:47:58
1 file - 2 blocks used
TOTAL: 2 files - 4 bytes - 2 directories - 8 blocks used
9.RAM Disk:> lha -r a test.lha test
LhA Freeware Version 2.15 AOS4
Copyright (c) 1991-94 by Stefan Boberg.
Copyright (c) 1998,1999 by Jim Cooper and David Tritscher.
Copyright (c) 2004-2011 by Sven Ottemann.
Creating new archive 'test.lha':
Stored: ( 0.0%) 4 => 4 : test/bar
Stored: ( 0.0%) 0 => 0 : test/bash/foo
2 files added, all files OK.
Operation successful.
lha does not appear to archive directories at all, only files, QED
It is capable of archiving empty directories though. I wonder how that's done. I guess if it's empty, it'll archive it differently. If there's files in it, there's no need to archive just the directory.
So I guess I just never noticed before. 20 years of not noticing :-/
Not necessarily. In OS4.1 (if not earlier) they change the behaviour of date stamps on folders:
Before that AmigaOS only updated the date stamp for changes immediately inside the folder. i.e. Changing the file given by the path "Volume:One/Two/Three/File" would only change the date stamp of folder "Three".
But after that AmigaOS (at least for some filing systems) updates the date stamp OF ALL CONTAINING FOLDERS all the way. i.e. Changing the file given by the path "Volume:One/Two/Three/File" would change the date stamp of folders "Three", "Two" AND "One".
If XAD/LhA were written with the former folder behaviour in mind, then they **might** have set the folder date after extracting all the files in the immediate folder. That would have avoided new files causing the folder's date to change. But with the newer folder behaviour, this "work-around" would no longer work reliably.
IMHO it's not >AmigaOS< responsible for that but the underneath FileSystem. And to my own memories FFS2 always featured this like that. Maybe SFS/SFS2/JXFS did not until OS 4.1 I don't know.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
