bobmon@iuvax.cs.indiana.edu (RAMontante) (09/15/90)
brad@looking.on.ca (Brad Templeton) <1990Sep14.212200.6207@looking.on.ca> : | | A *zip* for unix would be used to create archives for ms-dos users in ZIP | format, and I suppose to create archives for unix users using the unix | unzip, although that's far less common a use. I use the "lharc" program to archive and compress files on various unix machines, specifically to manage related groups of data files which I need to move around or hang onto. I much prefer it, as it is more efficient at compression than "compress" and more convenient to use than "tar"; and vastly more convenient than the tar/compress combination. I suppose a unix zip would have similar advantages, and might achieve slightly better compression for some files if MS-DOS experience is a guide, but I am pleased enough with lharc's performance *and* its availability that I really don't much care about zip. Of course, PKZIP on my MS-DOS box is faster than lharc, but that does not mean that a public-domain zip for unix boxes would be faster than unix lharc; and the speed really isn't much of a concern except when I run a single-tasking "O.S." on an 8088 with a slow disk drive. -- disclaimer: This opinion has been compressed by discarding all the 0 bits and only transmitting the 1 bits.
ts@uwasa.fi (Timo Salmi LASK) (09/16/90)
In article <58772@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >brad@looking.on.ca (Brad Templeton) <1990Sep14.212200.6207@looking.on.ca> : >| A *zip* for unix would be used to create archives for ms-dos users in ZIP >| format, and I suppose to create archives for unix users using the unix >| unzip, although that's far less common a use. > >I use the "lharc" program to archive and compress files on various unix >machines, specifically to manage related groups of data files which I (The following is just an observation, not an opinnion on which archiver should be used). The fact that we do not have zip for unix is inconvenient, since there is one feature in zip which is useful in moderating an ftp site. This is the fact that the datestamp of a .zip can very easily be set to be the same as the date of the latest file within the acrhive. This information is nice to have in maintaining archives, because it is easy to see which files are recent, which not. The problem with this approach is that the file has to be first transferred to a PC, and then back, but that is necessary for testing and virus checking anyway. ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (09/17/90)
In article <58772@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: | I use the "lharc" program to archive and compress files on various unix | machines, specifically to manage related groups of data files which I | need to move around or hang onto. I much prefer it, as it is more | efficient at compression than "compress" and more convenient to use | than "tar"; and vastly more convenient than the tar/compress combination. I agree with you about the compression, but it is slower than compress, zoo, zip, or 300 baud modems. It lacks comments on files and the archive as a whole (at least the one I have does). There is a new 2.0beta version for DOS which is (not* available to the public, but which should be by the end of the year. It isn't much faster, but has better compression. It beats every compressor I've ever seen for that, including zip with flags set. It has *not* been ported to UNIX. I believe that a new version of zoo will be coming which uses a new high performance packing method. This would give all the advantages in features, while adding better compression. -- 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
mlord@bwdls58.bnr.ca (Mark Lord) (09/18/90)
In article <1990Sep15.202211.24997@uwasa.fi> ts@uwasa.fi (Timo Salmi LASK) writes: >(The following is just an observation, not an opinnion on which >archiver should be used). The fact that we do not have zip for unix >is inconvenient, since there is one feature in zip which is useful >in moderating an ftp site. This is the fact that the datestamp of a >.zip can very easily be set to be the same as the date of the latest >file within the acrhive. This information is nice to have in >maintaining archives, because it is easy to see which files are >recent, which not. The problem with this approach is that the file >has to be first transferred to a PC, and then back, but that is >necessary for testing and virus checking anyway. Errr.. but yes, it must be transferred to the PC for testing/virus check, but NOT the other way again! You've already got it on the UNIX, so why double one's time transferring it back again. My apologies, I couldn't resist. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
ts@uwasa.fi (Timo Salmi LASK) (09/19/90)
In article <4376@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >In article <1990Sep15.202211.24997@uwasa.fi> ts@uwasa.fi (Timo Salmi LASK) writes: >>(The following is just an observation, not an opinnion on which >>archiver should be used). The fact that we do not have zip for unix >>is inconvenient, since there is one feature in zip which is useful >>in moderating an ftp site. This is the fact that the datestamp of a >>.zip can very easily be set to be the same as the date of the latest >>file within the acrhive. This information is nice to have in >>maintaining archives, because it is easy to see which files are >>recent, which not. The problem with this approach is that the file >>has to be first transferred to a PC, and then back, but that is >>necessary for testing and virus checking anyway. > >Errr.. but yes, it must be transferred to the PC for testing/virus check, >but NOT the other way again! You've already got it on the UNIX, so why >double one's time transferring it back again. My apologies, I couldn't resist. Ah, but there may be nothing to resist :-) since you might not have thought of all the angles. There is no guarantee, that the .zip file on the Unix system has the correct date (in practice incorrect dates are frequent). Since there is no zip for Unix, and I haven't figured out a system to change the date on BSD 4 (or whatever we have) Unix, the calistechnics is necessary until some kind soul points out how the original .zip's date can be adjusted on Unix. Then there is my (im)mortal sin of adding chyde.uwasa.fi information header to the .zip files at our site, and that also requires the two-way traffic. ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
robl@idca.tds.PHILIPS.nl (R. Luursema) (09/21/90)
In article <1990Sep19.074343.22346@uwasa.fi> ts@uwasa.fi (Timo Salmi LASK) writes: >Ah, but there may be nothing to resist :-) since you might not have >thought of all the angles. There is no guarantee, that the .zip >file on the Unix system has the correct date (in practice incorrect >dates are frequent). Since there is no zip for Unix, and I haven't >figured out a system to change the date on BSD 4 (or whatever we >have) Unix, the calistechnics is necessary until some kind soul >points out how the original .zip's date can be adjusted on Unix. > You can modify the files date under Unix, using touch. Usage: touch [-amc] [MMDDhhmm[YY]] files... Though in the X/open manual the setting of a date is flagged as possible unsupportable (on certain flavours of unix). Our System V does support it, Apollo BSD Unix 4.2 does NOT support it, The MKS toolkit on DOS does support it. Rob. -- #---------------------------------------# ______ # Rob Luursema, BS-HW, V1b2 ext 2246 # /____ / organized # Philips Information Systems Apeldoorn # /____ / like the # Domain: robl@idca.tds.philips.nl # /____ / tower of # UUCP: ..!hp4nl!philapd!robl # /____ / pisa ... #include <std/disclaimer> # /____ / #---------------------------------------# ======== A good workman is known by his tools
ts@uwasa.fi (Timo Salmi LASK) (09/21/90)
a.tds.philips.nl> Sender: Followup-To: Distribution: Organization: University of Vaasa Keywords: In article <889@idcapd.idca.tds.philips.nl> robl@idca.tds.PHILIPS.nl (R. Luursema) writes: >In article <1990Sep19.074343.22346@uwasa.fi> ts@uwasa.fi (Timo Salmi LASK) writes: >>points out how the original .zip's date can be adjusted on Unix. : >You can modify the files date under Unix, using touch. > Usage: touch [-amc] [MMDDhhmm[YY]] files... : No, I can't, and that's the whole point. (For general information: If you have been following the whole thread, you'll see how this relates to binaries). The above applies only to certain brands of Unix (such as V as you point out), and does _not_ solve my problem of keeping correctly dated files at ftp sites. But now we are starting to drift away from the main subjects of c.b.i.p.d, and have perhaps to find a better suited forum. My apologies for the other readers. ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun