T.R | Title | User | Personal Name | Date | Lines |
---|
3734.1 | | CLO::COBURN | Growing older, but not up... | Tue May 01 1990 09:35 | 5 |
| I'm impressed - only 2-3 hours. I would have taken a lot longer.
I have a copy and I'll let you know if I have any problems.
John
|
3734.2 | LHarc VMS... | AKOV11::SMITH | Reality, just a visible imagination? | Tue May 01 1990 09:36 | 4 |
| Nice job Steve!
...Ed
|
3734.3 | Trying...???!!! | VIVIAN::S_GOLDSTEIN | Steve G...DTN:-847-5415 or 071-936-5415 | Tue May 01 1990 11:53 | 4 |
|
I'll try and let you know...
Steve G
|
3734.4 | Alright! | OOTOOL::SOO | We need the machine that goes *ping*. | Tue May 01 1990 14:33 | 5 |
| Thanks Steve.
Another test site here.
-=Chong=-
|
3734.5 | | CGOFS::DREW | Steve Drew | Tue May 01 1990 17:03 | 7 |
|
Just a note that there's still some work to be done with file name
translations, files will spaces and illegal VMS file name characters
cannot be extracted at present.
/Steve
|
3734.6 | | MSVAX::BARRETT | Have your people call my people | Tue May 01 1990 17:46 | 6 |
| I'll wait then. Suggestion: Turn spaces and invalid characters into
underscores. Don't forget to handle Amiga filenames that have more
than 1 period in them also.
Looking forward to it !!
|
3734.7 | Count me in, too! | YUPPIE::WILSON | Tony, the HOSS TRUMPET | Thu May 10 1990 11:55 | 3 |
| I'm late getting into this. Will try it out also.
Regards, Tony
|
3734.8 | | WJG::GUINEAU | | Thu May 10 1990 14:05 | 5 |
| I've been using it on wjg to list archives and extract files with no problems.
Great addition to the arc/zoo set
joh
|
3734.9 | New Version with Full Wild card support | CGOFS::DREW | Steve Drew | Fri Jul 06 1990 02:08 | 52 |
|
Well, after changing/adding a heck of alot of code. I
managed to get full will card support for LHARC/VMS and the
source code is still compatable with U**X systems, I am also
running it under ULTRIX with no problems. I'll make the
source available when it's cleaned up.
New image in CGOU01::AMNEW:LHARC.EXE
o Additions to version 1.01.
- File names are displayed in VMS format.
- Full wild card support for adding/extracting/deleting and so on.
Has even better control than zoo. As you can extract files from
certain subdirectories or all subdirectories or just top level.
You can use VMS or unix wildcarding.
example:
$ LHARC x FF347.LZH [*...]README
The above command would get all readme files from the top level
and all subdirectories of the archive file FF347.LZH, and creates
subdirectories to place them in. Use 'LHARC xi' to place them all
in your current directory or 'LHARC xc' to confirm each file.
$ LHARC X FF347.LZH README
Justs gets the README file from the top level directory.
- VMS modified/creation date stamp support. When extracting a
file from an archive onto a VMS machine the creation date and
revised date is set to date/time from the archive. (Like its
suppose to.) This does not work in Zoo for vms.
- New option 'c' can be applied to any command, and will cause
LHARC to ask confirmation on any add/extract/delete for each
file.
- bug fixes... and probably other things I've forgotten already.
I'll try and get a doc file/man page typed up time permitting.
Please give it a try and all comments/suggestions welcome.
/Steve.
|
3734.10 | | WJG::GUINEAU | | Fri Jul 06 1990 11:27 | 6 |
| Finally a decent archive utility with real vms/unix file manipulation
capability!
Great work, Steve!
john
|
3734.11 | More info on use of LHARC | CGOFS::DREW | Steve Drew | Fri Jul 06 1990 13:53 | 63 |
|
This image was linked against a VMS 5.3 system. If you run it on a VMS
system running less than 5.3 you will get a shareable library mismatch
error. To solve this I have relinked the image including the RTL which
makes the image 3 times bigger, but allows it to run on any version of
VMS. I called this image CGOu01::AMNEW:LHARC_WITH_RTL.EXE. So if you
are running less than 5.3 copy this image, and rename it to LHARC.EXE.
Also heres some more hints on LHARC.
LHARC d (delete command)
--------------------------
One of the good uses of lharc is to be able to delete and repack the
archive removing the files that you don't wont. For example if your
interested in fish disk FF346, but only in a few of the programs on
that disk. To save download time you could remove this from the archive
via:
LHARC d FF347 [.Packetsupport] [.wbd] [.Patchntsc] [*...]*.c [*...]*.h
This would delete the 3 directoires and their contents and also all C
source files and .h files from every directory.
Alternately you could provide the 'c' option to the delete command and
be prompted for each file that you wish to delete:
LHARC dc FF347 *
When deleting from Archive LHARC saves a copy of the archive before any
changes were made in a file called FF347.BAK, therefore you can recover
anything deleted on the last command.
You will notice that for big archives the delete command takes a while
to complete as it repacks the archive. ZOO does this differently: it
does not remove the file from the archive until you manually repack it
with the ZOO P command. So it is best to do all deletes on the same
command line rather than running 'LHARC d' multiple times.
LHARC f (freshen command)
---------------------------
The freshen command is the same as the ADD command except that it only
adds the file to the archive if it already exists in the archive and
the version you are adding is newer that the one in the archive.
Example:
$ LHARC x FF347 [.FME]*
$ Set def [.FME] ! since 'i' option not specified a new dir was created
$ Edit fme.asm ! change the source file
$ Set def [-] ! backup where we were
$ LHARC f FF347 [.FME]*.* ! note VMS wildcarding needs the dot.
[.FME]FMS.ASM - Added
$
LHARC u (update command)
------------------------
This is the same as the Add command but if the file is already in the
archive and not older than the disk version then dont add it.
|
3734.12 | Works great | CSC32::A_ANDERSON | Had Screw Driver did Travel | Fri Jul 06 1990 19:36 | 4 |
| Just tried the new version works great good job Steve!
Thanks
|
3734.13 | If it would only not add the VMS (.) | DNEAST::BAKER_CHUCK | | Tue Nov 13 1990 10:59 | 12 |
|
As a new VMS LHARC user I would like to know if there is some way
that I can add a file to an archive like the following:
lharc a archive-name.lzh filename.;
and in the archive see:
filename (without any .)
Chuck
|
3734.14 | Where is VMS LHARC now ??? | WBC::BAKER | Whatever happened to Fay Wrey... | Wed Feb 13 1991 09:51 | 8 |
|
Does someone else have copy of VMS LHARC on the net
which I might copy ?
I get messages about "Directory not found; volume
not software enabled" when I try to access it...
Thanks.
|
3734.15 | | CLO::COBURN | Growing older, but not up... | Wed Feb 13 1991 12:42 | 7 |
| re: .-1
You can try getting from CLOVAX""::DISK$USER1:[COBURN.PUBLIC]LHARC.EXE
for a short time.
John
|
3734.16 | Now on TAPE | ELWOOD::PETERS | | Wed Feb 13 1991 14:25 | 9 |
|
I have moved a copy of LHARC.exe to
TAPE::AMIGA:[AMIGA.tools]LHARC.exe
Steve Peters
Tape system manager
|
3734.17 | source available? | NAVIER::LONG | $SET DOG/IQ=ANY_POSITIVE_VALUE | Wed Apr 17 1991 11:53 | 9 |
| re: .9
>> I'll make the source available when it's cleaned up.
Steve,
Clean or not, is the source available somewhere. I need an Ultrix and
MS-DOS version.
Thanks,
Dick
|
3734.18 | yes | CGOFS::DREW | Steve Drew | Thu Apr 18 1991 12:19 | 12 |
|
Dick,
The sources are available from CGOFS::DISK$73G:[DREW.LHARC]*.*
You can also copy an ULTRIX (mips) version from CGOU11::"lharc"
The only thing I ask is if you make any changes please let me know
so I can keep the source updated.
/Steve.
|
3734.19 | many thanks | NAVIER::LONG | $SET DOG/IQ=ANY_POSITIVE_VALUE | Thu Apr 18 1991 12:43 | 0 |
3734.20 | Obscure bug... | CFSCTC::CARR | Guru: a 4-letter word to Amiga owners | Fri Aug 02 1991 00:23 | 43 |
|
Found a really obscure bug with VMS lharc (v1.01). I've been trying to
back up all my directories with lharc for a move to a new position within
the company. (VMS backup is out of the question, if you're wondering,
due to disk quotas on both systems - not enough room to generate the
save set).
I'd give a command: lharc a dmc.lzh [carr...]*.*
and watch the compression messages as it walked thru all my subdirectories
and create a wonderfully compressed lzh file. Upon listing or testing
the archive, it would fail with a crc error at one particular file. I
moved that file to a subdirectory and tried archiving just my top level
directory. Upon unpacking, it would fail at a different file. After much
head scratching, I figured out what's common about these files. They were
all created via dcl command procedures, using dcl write commands and have
similar file attributes:
Directory DISK$CFSUSER02:[CARR]
TAPE-DIRS.SUB;1 File ID: (17538,15,0)
Size: 1/3 Owner: [3MA,CARR]
Created: 7-MAR-1991 23:22:49.98
Revised: 7-MAR-1991 23:23:22.09 (1)
Expires: <None specified>
Backup: 8-MAR-1991 17:18:01.94
File organization: Sequential
File attributes: Allocation: 3, Extend: 0, Global buffer count: 0, No version limit
Record format: VFC, 2 byte header, maximum 27 bytes
Record attributes: Print file carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Total of 1 file, 1/3 blocks.
Deleted these files and all was ok. Not quite sure why lharc chokes on
them, but just a word of warning to those who might stumble down a
similar path.
-Dom
|
3734.21 | I think you'll find *lots* more "bugs" AFTER the move | BOMBE::MOORE | Amiga: Where 'multimedia' REALLY began | Fri Aug 02 1991 00:54 | 8 |
| Dom,
LHarc does not preserve record attributes, which are very important to
many VMS applications. I'm afraid you will discover that many of the
files you transfer in this manner will not function properly after you
unpack them onto the new system.
VMS Backup really is the proper way to transfer VMS files.
|
3734.22 | Still prefer lharc but you go with what works | CFSCTC::CARR | Guru: a 4-letter word to Amiga owners | Fri Aug 02 1991 22:00 | 15 |
| Re: -.1
> LHarc does not preserve record attributes, which are very important to
> many VMS applications. I'm afraid you will discover that many of the
> files you transfer in this manner will not function properly after you
> unpack them onto the new system.
> VMS Backup really is the proper way to transfer VMS files.
Yup, as I found out after trying to unpack the archive. It was a nice
try, but I eventually wound up making smaller savesets of my subdirs
via backup and unpacking/deleting them to get around the quota problem.
Sure wish backup did compression.
-Dom
|