Why i ask, that because i meet some strange problem:
I do pack some archive like this:
Quote:
lha -H0 a -r -e archive.lha #?
Now, while archive ok and all files seems to be visibly on os4, in total commander on win32, when i come to the directory i didn't see some of the files.
Yes, one may say "so go check your total commander with lha unpacker in", but then, i packed the same files before (few weeks ago), and total commander show them all just fine.
It looks like or archive simple broken still (just by luck didn't bring error on os4), or something weird happens somewhere..
More of it archive start to contain some files which shouldn't be there (i.e. like some self created file inside with of archive with name of archive). Or, like some copy of some file with different name in other place (and not where it should be)
@Raziel Yes of course i change some bits into directory which i want to pack, but how it can have any meaning to the whole general packing and making some files be missing to be viewed and creating files i don't have inside with content from other files ? It just seems like it create broken archives now which by luck kind of work.
Also, what i do lately is install this: http://os4depot.net/share/library/misc/xad_lha.lha due to "Underscrores instead of Spaces when unpacking" , but not sure if it can have any impact on the packing by pure lha..
kas1e wrote:@Raziel Yes of course i change some bits into directory which i want to pack, but how it can have any meaning to the whole general packing and making some files be missing to be viewed and creating files i don't have inside with content from other files ? It just seems like it create broken archives now which by luck kind of work.
Also, what i do lately is install this: http://os4depot.net/share/library/misc/xad_lha.lha due to "Underscrores instead of Spaces when unpacking" , but not sure if it can have any impact on the packing by pure lha..
Wtf..
That won't have any effect on packing, only on unpacking with XAD (Unarc/etc).
You are also specifying header level 0, which doesn't show up that bug anyway.
Maybe try packing with the default header level (2 I think), and see if that helps? There are issues with level 0 which is why the default was changed.
I've noticed that header level 0 will just fail/skip to archive some files that have too long paths and/or long file comments on them. Solution is to use header level 1 or 2 for that.
@all Seems at least H2 produce archive without additional file in the root and in total commander all files can be seen.. at least fir brief check.
@jpv Strange that files which were invisibly in totalcommander are in root of archive, and small by names. All looks like that something mess up archive a bit when i use H0, and this cause issues such as invisibly files/dirs and new additional files creations. Like filestructure mess up when lha pack it
@jpv Strange that files which were invisibly in totalcommander are in root of archive, and small by names. All looks like that something mess up archive a bit when i use H0, and this cause issues such as invisibly files/dirs and new additional files creations. Like filestructure mess up when lha pack it
Maybe H0 issues appear in different way depending of the LhA port/version? I've mostly tested it with MorphOS LhA... maybe it skips files in these cases, but your version messes the file structure? In any case I have stopped to use H0, especially when archiving deep directory structures like the system partition, and RNOArchive doesn't use it either.
Files not skipped: i can see them when i list in dopus4 on os4, but when i tried to check them in total commander on win32 : then there is none of some files. Sometimes, ready archive simple corrupted (even on os4). Once i switch to -H2 all going well (at least, visually in brief check).
Pretty strange! -H0 mean to have all go without compression, so kind of expected to put files as it..
Pretty strange! -H0 mean to have all go without compression
No it doesn't, -H is just the header format and it doesn't affect to the compression. It's just what information about files is written and it would be quite logical that if something messes file names/structure, it is related to the headers.
To go without compression you would have to use the -z option.
Edit: Quote:
Oh, i find out why i use -H0 , that why:
That's an issue with the unarchiver. I wouldn't use -H0 just for a hack for a certain unarchiver program when other levels do work with spaces with other unarchivers just fine.
But probably there is no other way to bugfix around it, only by pointing out on needs to install proper version of unpacking tools.
Simple solution: don't create content with spaces :) I avoid using spaces on all my filenames always, because throughout the history they have caused problems everywhere.
That's an issue with the unarchiver. I wouldn't use -H0 just for a hack for a certain unarchiver program when other levels do work with spaces with other unarchivers just fine.
Yeah, that's an old bug in the LhA module of XAD (I think v13 only). My external module fixes it. You can also use an up-to-date version of xadmaster. I think it did finally get updated in one of the OS4 updates.
News feed
OS4 Feedback forum
OS4Depot Feedback 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
Donate
