.Z file unhappiness

[GoogleCodeExporter]

It appears like The Unarchive has trouble with some .Z files (which are handled 
OK by 
BOMArchiveHelper). I ran into this with this file:

http://webdoc.sub.gwdg.de/ebook/e/1999/mathgoe/preprint/mg.97.17.dvi.Z

Decompressing it gives an error message about an input buffer overflow.

(I also had the impression that The Unarchiver doesn't register properly with 
launch services for .Z 
files. It doesn't show up in the Open With menu for them.
)

Original issue reported on code.google.com by cv4...@gmail.com on 19 Jan 2010 at 1:45

[GoogleCodeExporter]

I have no idea why Launch Services doesn't like The Unarchiver's .Z, it 
registers it 
exactly like all other files, but it doesn't work no matter what. There's some 
mysterious internal Launch Services conflict somewhere, probably, which is 
almost 
impossible to debug. If anybody can figure out any hints of what's going on 
there, it'd 
be most appreciated.

Also, I'll have a look at that file when I get back to working on The 
Unarchiver.

Original comment by paracel...@gmail.com on 19 Jan 2010 at 1:53

[GoogleCodeExporter]

Cool.

I had a look at the UTIs as well and couldn't figure it out yet. Generally I 
think the app shouldn't need to define 
its own UTI for the file type as public.z-archive is provided by the system 
already. 

Another remark: I have set The Unarchiver up to automatically trash files after 
decompressing them. It seems 
that it will also trash the file in this situation, where decompression fails. 
I'd consider that unfortunate behaviour 
as well.

Original comment by cv4...@gmail.com on 19 Jan 2010 at 1:58

[GoogleCodeExporter]

OK, I fiddled a bit more (and switched accounts which seems to be one of the 
things one has to do from time 
to time when messing with Launch Services) and it seems that I can get the app 
to register correctly for .Z by 
removing the entry (#16) for cx.c3.compress-archive in imported UTIs and 
setting the Document Type for 
Unix Compress Files (#15) to use the LSItemContentTypes public.z-archive 
instead of the custom one used 
previously.

One should probably try to make sure that the public.z-archive UTI is 
pre-defined in all OS versions 
supported by the app before going with this (and otherwise, I guess, import 
_that_ UTI).

Hope this description makes sense.

Original comment by cv4...@gmail.com on 19 Jan 2010 at 2:06

Attachments:

• Info.plist

[GoogleCodeExporter]

I think this should be fixed now. I changed the imported type to be 
public.z-archive too because I am pretty sure 
that didn't use to exist.

Original comment by paracel...@gmail.com on 9 Apr 2010 at 11:44

• Changed state: Fixed