Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: ChaosLord on September 29, 2011, 05:28:17 PM
-
I had this problem last week but I forgot to paste my notes to the forum.
I am backing up my Amiga hard drive by making lha archives of each partition and then copying over Ethernet to my slave bgcpc.
Original was: 555,403,364 bytes 42,727 files 1549 dirs 1152925 blocks used
I lhaed the files and copied over to pc
After 7zip extract was: 552,818,263 bytes 42,731 files 1534 folders
Ok I can explain that the dirs went down from 1549 to 1534 by assuming that 7zip prob has the same bug that ALL GUI lha archivers have: They never decompress empty dirs! GRRRRRR
But the number of FILES went UP. 7zip created me 4 new files that I never had b4. Wow! I wonder if it can write code for me too?
While I was unzipping, 7zip produced from very bizarre errors: it kept extracting nonexistant files with the same name as the archive. These files were around 700K each. The REAL files were smaller and had real, normal names and were associated with A500 TC Jospels/Tools/ (Jospels is where my bro put his gfx)
So it did this 4 times. I thought since 4 files overwrote each other that I would be MISSING 4 files, not GAIN 4 files. Man this is weird!!!!
Like if I named the archive blah.lha then it would extra 4 files named blah. So I renamed the archive to a.lha then it extracted 4 files named a. This just totally blew my mind.
-
I had this problem last week but I forgot to paste my notes to the forum.
I am backing up my Amiga hard drive by making lha archives of each partition and then copying over Ethernet to my slave bgcpc.
Original was: 555,403,364 bytes 42,727 files 1549 dirs 1152925 blocks used
I lhaed the files and copied over to pc
After 7zip extract was: 552,818,263 bytes 42,731 files 1534 folders
Ok I can explain that the dirs went down from 1549 to 1534 by assuming that 7zip prob has the same bug that ALL GUI lha archivers have: They never decompress empty dirs! GRRRRRR
But the number of FILES went UP. 7zip created me 4 new files that I never had b4. Wow! I wonder if it can write code for me too?
While I was unzipping, 7zip produced from very bizarre errors: it kept extracting nonexistant files with the same name as the archive. These files were around 700K each. The REAL files were smaller and had real, normal names and were associated with A500 TC Jospels/Tools/ (Jospels is where my bro put his gfx)
So it did this 4 times. I thought since 4 files overwrote each other that I would be MISSING 4 files, not GAIN 4 files. Man this is weird!!!!
Like if I named the archive blah.lha then it would extra 4 files named blah. So I renamed the archive to a.lha then it extracted 4 files named a. This just totally blew my mind.
do not use 7zip or zip or ace to backup amiga files
they are not specially designed for the amiga files
when you decrunch that compressed files you can lost comments and the correct date of the original files...also you can have problems with empty dirs and prblems with protection
use lha or lzx
-
For best results you can lha/lzx with no compression and compress the resulting archive with 7z/lzma/xz. That way the amiga attributes are preserved while also getting the best compress ratio.
-
do not use 7zip or zip or ace to backup amiga files
I didn't. I made the archive with lha.
But I wanted to see if the archive survived the transfer thru my ancient Ethernet card to my bgcPC so I test extracted the files using 7zip.
-
I didn't. I made the archive with lha.
But I wanted to see if the archive survived the transfer thru my ancient Ethernet card to my bgcPC so I test extracted the files using 7zip.
Well 7zip lha implementation is quite buggy then.
-
Is the software set to break the archived file into 700KB chunks (i.e to fit on a 720K PC floppy) for some reason?
-
Is the software set to break the archived file into 700KB chunks (i.e to fit on a 720K PC floppy) for some reason?
I don't know anything about that. I don't understand what software you are talking about. The .lha archive was 333MB
-
I didn't. I made the archive with lha.
But I wanted to see if the archive survived the transfer thru my ancient Ethernet card to my bgcPC so I test extracted the files using 7zip.
On Windows I only trust LhA NT (http://aminet.net/package/util/arc/lhant) to extract Amiga LhA archives correctly.
do not use 7zip or zip or ace to backup amiga files
they are not specially designed for the amiga files
when you decrunch that compressed files you can lost comments and the correct date of the original files...also you can have problems with empty dirs and prblems with protection
use lha or lzx
Agree with that. Amiga 7za needs some serious work to support Amiga-style paths, ptotection bits and file comments whilst still maintaining compatibility.
It would probably be easier to add better compression schemes to LhA (such as LZMA2, or at least higher LZW variants that our LhA doesn't support but others do)
-
For best results you can lha/lzx with no compression and compress the resulting archive with 7z/lzma/xz. That way the amiga attributes are preserved while also getting the best compress ratio.
Yea, Linux users do something similar to preserve file attributes and directory structure. I believe they commonly use tar and then 7z.
@ChaosLord
I have used Piotr Bardurski's 7za 9.13 (06/07/10) with 'x' for extraction without noticing any problems here. I have tried the xad module for 7z off of Aminet and it was VERY buggy and didn't recognize the 7z files I tried. It would be great to have a 68k xad 7z client. I have "xad UnFile", "xad UnDisk" and "xad List" in Diskmaster which makes the Linux multiple compressed files easy except for 7z and RAR :(. I normally keep using "xad UnFile" on them until they are extracted without worrying about what format they are in.
-
I have tried the xad module for 7z off of Aminet and it was VERY buggy and didn't recognize the 7z files I tried.
I find that incredibly surprising, my inbox would be inundated with emails if that was the case.
To recognise files it simply looks for the file header "7z" (and the next few bytes, whatever they are). This is the official header for 7-Zip files, so if it isn't recognising them your files are probably the issue.
I'm aware of potential stack overruns but these won't occur until it hits PPMd decompression. Most 7-Zips use LZMA or LZMA2.
-
@Chris
It works now! Maybe I had tried an older version or maybe it was a different xad driver altogether that gave me problems before. Awesome! Recommended! Thanks!
Here's the Aminet link for everyone...
http://aminet.net/util/arc/xad_7z.lha
-
I had this problem last week but I forgot to paste my notes to the forum.
I am backing up my Amiga hard drive by making lha archives of each partition and then copying over Ethernet to my slave bgcpc.
Original was: 555,403,364 bytes 42,727 files 1549 dirs 1152925 blocks used
I lhaed the files and copied over to pc
After 7zip extract was: 552,818,263 bytes 42,731 files 1534 folders
Ok I can explain that the dirs went down from 1549 to 1534 by assuming that 7zip prob has the same bug that ALL GUI lha archivers have: They never decompress empty dirs! GRRRRRR
But the number of FILES went UP. 7zip created me 4 new files that I never had b4. Wow! I wonder if it can write code for me too?
While I was unzipping, 7zip produced from very bizarre errors: it kept extracting nonexistant files with the same name as the archive. These files were around 700K each. The REAL files were smaller and had real, normal names and were associated with A500 TC Jospels/Tools/ (Jospels is where my bro put his gfx)
So it did this 4 times. I thought since 4 files overwrote each other that I would be MISSING 4 files, not GAIN 4 files. Man this is weird!!!!
Like if I named the archive blah.lha then it would extra 4 files named blah. So I renamed the archive to a.lha then it extracted 4 files named a. This just totally blew my mind.
Just wondering, exactly where did you extract the files to? Have in mind that most archivers (including LhA) supports path lenghts of max 256 characters. This means that the destination path + paths in the archive can not exceed 256 chars upon extracting, if they do this the long paths may be truncated, and this in turn may lead to unpredictable results.
Some archivers use workarounds when dealing with files with long path names, here the files will first be extracted to a different location (with shorter path), and then they will be moved to the selected destination directory afterwards. Unfortunately this method can sometimes be a bit flaky, and I suspect that this may be the reason for the problems you are having.
Personally, I always use a short destination path when extracting files from really large archives, this is regardless of the OS, program or archive format used. On my pc for example, I have created a folder called "XXX" on my D: partition which is used for this exact purpose.
-
@chris
xadUnFile is back to crashing with your xad_7z installed again. I consistently get "Exception 6: chk instruction" with PC=$2e. I tried using MuForce but the system freezes when I do with no hits before it does. xad_7z worked the first time I installed it and rebooted but crashes now with the same archive. There's plenty of stack for xadUnFile according to Scout.
I used BDebug to catch a crashed task and it looks like there is a branch to PC=8 first. Back tracking from the last stack entry, I find xad_xfd+$3f0 doing a jsr to exec/OpenLibrary() opening xfdmaster.library version $26. I don't see any problems with the xad_xfd code. Removing xad_7z from Libs:xad/ stops the crashes. I'm surprised no one else has reported this problem. Versions used are...
xadmaster.library 12.1
xad_7z 2.4
xad_xfd 1.1
xadUnFile 1.25
My setup is a 3000T with CSMK3 68060 using AmigaOS 3.9.
-
When I back anything up I use tar with no compression (supports soft links too) then bz2 it with max compression...
not that I've backed anything up for a few years...
-
@chris
xadUnFile is back to crashing with your xad_7z installed again. I consistently get "Exception 6: chk instruction" with PC=$2e. I tried using MuForce but the system freezes when I do with no hits before it does. xad_7z worked the first time I installed it and rebooted but crashes now with the same archive. There's plenty of stack for xadUnFile according to Scout.
I used BDebug to catch a crashed task and it looks like there is a branch to PC=8 first. Back tracking from the last stack entry, I find xad_xfd+$3f0 doing a jsr to exec/OpenLibrary() opening xfdmaster.library version $26. I don't see any problems with the xad_xfd code. Removing xad_7z from Libs:xad/ stops the crashes. I'm surprised no one else has reported this problem. Versions used are...
xadmaster.library 12.1
xad_7z 2.4
xad_xfd 1.1
xadUnFile 1.25
My setup is a 3000T with CSMK3 68060 using AmigaOS 3.9.
xad_xfd 68k version definitely doesn't work, remove it and see if that also stops xad_7z crashing.
-
xad_xfd 68k version definitely doesn't work, remove it and see if that also stops xad_7z crashing.
You are right Chris. I removed xad_xfd and xad_7z is working again. It's odd that xad_7z worked with the bugged xad_xfd when I first installed it. Thanks again.