Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: Piru on January 02, 2011, 12:14:25 AM
-
LhA archiver has a bug in it that results in year beyond 2010 to get archived as 1980. All Amiga LhA versions have this issue.
Until LhA fix is provided you should be aware of this issue for example when using LhA for backup purposes. Similarly you should be careful when uploading LhA archives to aminet or other collections.
MorphOS LhA 2.7.10 fixes this issue. MorphOS users can download the new LhA command from: http://www.morphos-team.net/downloads.html.
Other vendors will hopefully provide similar fixes soon.
UPDATE: AmiNET has new bug fixed LhA now: http://aminet.net/package/util/arc/lha_68k
-
Now that was quick!
-
Now that was quick!
Actually it was at least a day too late for me :-/ Didn't see this until now.
-
When we get x86 version of morphos? x86 is future an we want to have future OS. I'm sure that Msi range of mobos would be good choise.
Currently morphops supports only DEAD mobos, that is not a good thing
Meanwhile, back on topic...
Thanks for the update, Piru et al.!
-
Fast work Piru! :ThumbsUp:
Did you have to change the format of lha archives to implement the fix?
How did you fix it?
What year will the next lha bug strike?
-
Did you have to change the format of lha archives to implement the fix?
No.
How did you fix it?
There was a bogus comparison against the datestamp year being greater than 2010. I can only presume the original author meant 2100. Anyhow, now it correctly compares against 2107 which is the last year the date format used can present.
What year will the next lha bug strike?
2108 the latest.
-
@Piru
There was a bogus comparison against the datestamp year being greater than 2010. I can only presume the original author meant 2100. Anyhow, now it correctly compares against 2107 which is the last year the date format used can present.
Thanx for the .info!
@All Haxx0rz out there:
Can anyone hackpatch the old lha v1.38r 680x0 asm coded version?
The 1.3x series of LHA commands by Stefan Boberg were coded in asm and were noticeably faster than the lha 2.x series coded in C by various ppl.
I need a lha1.3x for use on slow old Real Amigas. Thanx a Megabyte! :)
-
Ok, I'll fix the 68k version...
The lastest is the 2.12 ?
-
Ok, I'll fix the 68k version...
The lastest is the 2.12 ?
Don't bother with 2.x. There's already 2.15 being uploaded to aminet.
These are the versions that require binary patching:
http://aminet.net/util/arc/LhA_e138.run
http://aminet.net/util/arc/lha150r.run
You'll probably find the spot easily by looking for "cmp.s #2010,dn"
-
No need for error prone patching using outdated versions of lha...
Sven Ottemann already made the necessary fixes, including the 68k version.
It will hit Aminet shortly.
OS4 version is in the upload queue of os4depot already.
-
Please, first, explain the bug : all .lha created with the v2.12 or the v1.38 give me the correct date : 2/2/2011
(WinUAE is used)
-
No need for error prone patching using outdated versions of lha...
Sven Ottemann already made the necessary fixes, including the 68k version.
Did you read the post (http://www.amiga.org/forums/showpost.php?p=603372&postcount=8) by ChaosLord?
-
Please, first, explain the bug : all .lha created with the v2.12 or the v1.38 give me the correct date : 2/2/2011
Both 1.38 and 2.12 give 1980 here. BTW 2/2 doesn't sound correct it's january still.
-
@piru:
No, I referred to Cosmos.
I think that you should be able to perform the correct patches to the Boberg Amiga lha versions ;-)
Would be a nice move to still support unaccelerated 68k machines.
-
>Both 1.38 and 2.12 give 1980 here.
With WinUAE ??
> BTW 2/2 doesn't sound correct it's january still.
Oups... I wanna say 2/1 of course !
-
>Both 1.38 and 2.12 give 1980 here.
With WinUAE ??
No, MorphOS.
Just to clarify: the files added to the archive have a wrong year, not the archive file itself.
-
Thankx Twat!!! ;)
Sorry, that word is stuck in my head now.
Really though, thankx a lot for all you've done Piru!
-
Oups... I wanna say 2/1 of course !
On lha 1.38
lha a -rade t:Cosmos.lha #?
cd t:
lha x Cosmos.lha
Now look at the extracted files. You will have just time travelled back to 1980. :lol:
Make sure not to use the -E option. -E is different from -e and causes extracted files to be touched.
My lha2.12 has a -Or option that "skips datestamp check". Does anyone know what that does?
-
... You will have just time travelled back to 1980. :lol:
Maybe not so bad - all the girls I knew then seemed like 30 years younger than the ones I know now.
On the other hand, no Amigas, just Jay Miner Atari 800's, which were fun at the time.
-
Could this be why some file I UN-LHA'd today we're locking up my system?
-
Could this be why some file I UN-LHA'd today we're locking up my system?
No
-
Fixed OS4, 68K and WOS versions are now on Aminet.
-
Fixed OS4, 68K and WOS versions are now on Aminet.
Sweet.
-
My lha2.12 has a -Or option that "skips datestamp check". Does anyone know what that does?
I think that should be -Qr
`-Qr' (add) Skip datestamp check
This option, when on, disables the datestamp comparison for
the update (`u') and freshen (`f') commands, so that the files
that already exist in the archive will be replaced regardless
of file modification dates.
This option is OFF by default for all commands but `r'.
-
@All Haxx0rz out there:
Can anyone hackpatch the old lha v1.38r 680x0 asm coded version?
The 1.3x series of LHA commands by Stefan Boberg were coded in asm and were noticeably faster than the lha 2.x series coded in C by various ppl.
I need a lha1.3x for use on slow old Real Amigas. Thanx a Megabyte! :)
In version 1.38 the offending instruction is cmpi.l #$7DA,d6 and can be located at offset $BC1A. The actual incorrect data is at offset $BC1E.
The simple fix is to load your favorite hex editor and change the 2 byte word at offset $BC1E from $07DA (2010) to $083B (2107). This worked like a charm for me.
I did find another problem when listing the contents of an lha archive with v1.38. The year portion of the date in the final summary line contains 3 digits, so that 08-Jan-11 reads as 08-Jan-111. I've found the location of this bug in the code also. It appears that the rounding function is not called when printing the date for the last line, but it is called when printing the archived files list. I'm working on a fix for this also and I'll upload it when I'm done.
-
I forgot to post this here, and it hasn't been mentioned:
xadmaster.library's internal LhA has a bug which shows up when extracting archives created with the new LhA - spaces in filenames are converted to underscores. A workaround is to use -H0 when creating archives.
The LhA client has been updated, MorphOS has the update already and OS4 users can download my externally-compiled version of the LhA client here (http://aminet.net/package/util/arc/xad_lha).
OS3 users do not have a fix as yet. Ideally, somebody needs to build xadmaster.library v13 for OS3; The source is available here (http://libxad.sf.net).
Chris