lim@cluster.cs.su.oz.au (Hong Lip Lim) (02/21/91)
I have found out that if the name of a UNIX file contains more than one dot character (say TEST.1.2), then if I compress them using the lharc program on UNIX and then try to decompress it on the PC (using lharc x lzhname) , I get the following message: LHarc 1.13c (c) Yoshi, 1988-1989 Can't write file : 'TEST.1.2' One way of course is to ensure that the UNIX files do not contain multiple dots in their names. But if that is not possible, is there an improved version of the lharc program on the PC that does not have this problem? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hong Lip Lim Email: lim@cs.su.oz.au Department of Computer Science Phone: 61 2 692 4276 University of Sydney, Australia, NSW2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/23/91)
In article <2108@cluster.cs.su.oz.au> lim@cluster.cs.su.oz.au (Hong Lip Lim) writes: | One way of course is to ensure that the UNIX files do not contain | multiple dots in their names. But if that is not possible, | is there an improved version of the lharc program on the PC | that does not have this problem? There is no problem with lharc, the problem is that DOS can't accept reasonable filenames. The solution is to extract to stdout and redirect to a file with a restricted DOS name. No version of lharc can solve this, because information must be lost, and it's up to you to decide on a name mapping. Lharc and zip alos seem to lose the file permissions and turn readonly files into regular files. How very nice for them. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
roelofs@nas.nasa.gov (Cave Newt) (02/25/91)
lim@cluster.cs.su.oz.au (Hong Lip Lim) writes: >| One way of course is to ensure that the UNIX files do not contain >| multiple dots in their names. But if that is not possible, >| is there an improved version of the lharc program on the PC >| that does not have this problem? In article <3280@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > There is no problem with lharc, the problem is that DOS can't accept >reasonable filenames. The solution is to extract to stdout and redirect >to a file with a restricted DOS name. Insofar as this is an extremely well-documented limitation of MS-DOS, the problem IS lharc's. A multi-platform file utility should detect this and take appropriate action. > No version of lharc can solve this, because information must be lost, >and it's up to you to decide on a name mapping. On the contrary, Kai Uwe Rommel's extended version of lharc handles this with reasonable facility. All dots but the last get mapped to underscores, and either DOS or lharc truncates any "overhang." Unfortunately, there are one or two other bugs which don't appear in the just-DOS version...
valley@uchicago (Doug Dougherty) (02/26/91)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: >In article <2108@cluster.cs.su.oz.au> lim@cluster.cs.su.oz.au (Hong Lip Lim) writes: >| One way of course is to ensure that the UNIX files do not contain >| multiple dots in their names. But if that is not possible, >| is there an improved version of the lharc program on the PC >| that does not have this problem? > There is no problem with lharc, the problem is that DOS can't accept >reasonable filenames. The solution is to extract to stdout and redirect >to a file with a restricted DOS name. Actually, ZOO does a pretty good job with this. Admittedly, information can be lost, but all in all, ZOO is the way to go.
robl@idca.tds.PHILIPS.nl (R. Luursema) (02/27/91)
In article <3280@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >In article <2108@cluster.cs.su.oz.au> lim@cluster.cs.su.oz.au (Hong Lip Lim) writes: > >| One way of course is to ensure that the UNIX files do not contain >| multiple dots in their names. But if that is not possible, >| is there an improved version of the lharc program on the PC >| that does not have this problem? > > There is no problem with lharc, the problem is that DOS can't accept >reasonable filenames. ^^^^^^^^^^ U*IX will accept any character in filenames; some versions even accept 8-bit ascii. Do you think thats reasonable? Also here, if an archive is going to be spread over different machines, the creator of it has to keep portability into his mind. On the other hand, the portable archiver programs should be aware of portability issues by doing the right conversions and pass a correct filename to the OS. >The solution is to extract to stdout and redirect >to a file with a restricted DOS name. This will only work for text files, not binarys. > No version of lharc can solve this, because information must be lost, >and it's up to you to decide on a name mapping. Not if I didn't create the archive. The DOS versions of the portable arc programs should do the remapping to DOS naming restrictions. ZOO can do this. ARC and LHARC can't. I am curious what ZIP will do... -- _ _ / U | Rob Luursema, Philips Information Systems Apeldoorn /__ < robl@idca.tds.philips.nl 88 |_\ "The trouble with everyone is that they generalize too much"
mir@opera.chorus.fr (Adam Mirowski) (03/01/91)
In article <valley.667498486@gsbsun>, valley@uchicago (Doug Dougherty) writes: %% davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: %% >In article <2108@cluster.cs.su.oz.au> lim@cluster.cs.su.oz.au (Hong Lip %% >Lim) writes: %% >| One way of course is to ensure that the UNIX files do not contain %% >| multiple dots in their names. But if that is not possible, %% >| is there an improved version of the lharc program on the PC %% >| that does not have this problem? %% > There is no problem with lharc, the problem is that DOS can't accept %% > reasonable filenames. The solution is to extract to stdout and redirect %% > to a file with a restricted DOS name. %% Actually, ZOO does a pretty good job with this. Admittedly, information %% can be lost, but all in all, ZOO is the way to go. What I usually do is to edit the file with a binary/hex editor and substitute another characters in place of the dots. Because the header is under a checksum, it is necessary to change one of the letters to keep it constant. Anyway, maybe the new 2.05 version of lharc manages the name problem? As for the extracting to standard output, if lharc doesn't setmode(1,O_BINARY) then maybe it could be run from a program that does it before doing a system() call. -- Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74 Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX
ts@uwasa.fi (Timo Salmi) (03/02/91)
In article <8038@chorus.fr> mir@opera.chorus.fr (Adam Mirowski) writes: : >Anyway, maybe the new 2.05 version of lharc manages the name problem? : FYI, it's currently (/pc/pd2/)lha210e.exe. ................................................................... Prof. Timo Salmi Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.12.37 School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
mir@opera.chorus.fr (Adam Mirowski) (03/04/91)
In article <1991Mar2.075459.27590@uwasa.fi>, ts@uwasa.fi (Timo Salmi) writes: %% In article <8038@chorus.fr> mir@opera.chorus.fr (Adam Mirowski) writes: %% >Anyway, maybe the new 2.05 version of lharc manages the name problem? %% FYI, it's currently (/pc/pd2/)lha210e.exe. There are no docs in that package! lharc is maybe PD, but there is no reason to distribute it without instructions :-) -- Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74 Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX