On OpenVMS V8.3 With Info-zip 3.0 (July 5th 2008 ) (also confirmed with 2.2):
When I use "zip -m" to move files and directories owned by another owner in the same UIC group and granting G:RWED permission into an archive, SET-E-PRONOTCHG errors are reported for all subdirectories being moved. However, all files were successfully moved into the archive, so clearly the errors are spurious. Furthermore, such spurious errors may cause problems for any procedure calling zip, so these errors should be suppressed or if it is important for some reason to report them (I can't imagine why), at least downgraded to warnings.
Here is a failing test case:
$ create/dir/log [.testzip.subdir] %CREATE-I-CREATED, SYS$SYSDEVICE:[DYMAX.001007.TESTZIP.SUBDIR] created $ copy nla0: [.testzip]test.txt $ copy nla0: [.testzip.subdir]test2.txt $ old_privs=f$setprv("all") $ set file/prot=(s:rwed,g:rwed,o:rwed,w)/own=operate043 [.testzip...]*.*,[]testzip.dir $ restore_privs=f$setprv(old_privs) $ zip -m testzip.zip [.testzip...]*.* adding: [.TESTZIP.SUBDIR] (stored 0%) adding: [.TESTZIP]TEST.TXT (stored 0%) adding: [.TESTZIP.SUBDIR]TEST2.TXT (stored 0%) %SET-E-PRONOTCHG, protection on DSA0:[DYMAX.001007.TESTZIP]SUBDIR.DIR;1 not changed -SYSTEM-F-NOPRIV, insufficient privilege or object protection violation $ dir [.testzip...] %DIRECT-W-NOFILES, no files found $ unzip -l testzip.zip Archive: DSA0:[DYMAX.001007]testzip.zip;1 Length Date Time Name --------- ---------- ----- ---- 0 11-27-2009 09:08 TESTZIP/SUBDIR/ 0 11-27-2009 09:08 TESTZIP/TEST.TXT 0 11-27-2009 09:08 TESTZIP/SUBDIR/TEST2.TXT --------- ------- 0 3 files
The first obvious mystery is why you are even getting what looks like a DCL complaint from Zip. The answer appears to be some lame code in [.VMS]VMSZIP.C|deletedir():
system(strcat(strcpy(s, "set prot=(o:rwed) "), d)); r = delete(d);
It's trying to set the protection on the directory to allow deletion ("D" permission normally being absent), before trying to delete the thing. Sadly, as you've observed, this can be impermissible even when it's unnecessary. Because no one actually looks at the status returned by system() here, the failure has no consequence other than the message(s).
> [...] (also confirmed with 2.2):
It's _old_ lame code.
As a truly sleazy work-around, you could try changing the code to do something like this:
if ((s = malloc(len + 100)) == NULL) return 127;
system(strcat(strcpy(s, "pipe set mess/nofaci/noiden/noseve/notext ; set prot=(o:rwed) "), d));
That should suppress the message(s). (And VMS V8.x is new enough to have PIPE.)
Thanks for the complaint. I'll see if I can get some less lame code into Zip 3.1.
Well, we have a procedure that searches the logs for anything that looks like an error message. If there were any error messages, the procedure will not continue to the next step to give us an opportunity to investigate and manually fix anything before continuing, so the fact that no error $STATUS is returned is not the issue here. Any way we can work around the problem?
You mean other than changing the code as suggested already? Avoiding "-m" would help. Otherwise, setting the security (SOGW protections or ACLs) so that the SET PROTECTION command used by Zip will succeed.
It's based on internal-development Zip 3.1 code, and includes some additional fixes (which should be harmless, at worst), but I believe that it should be compatible with Zip 3.0 code.
I need to put it through more testing, particularly on older VMS versions, but it seemed to work for me on a test case like yours.
I don't know if you noticed (or care), but when you specify "[.testzip...]*.*", Zip does not archive the actual testzip.dir directory (or, hence, delete it because of "-m"). If you want that directory (with its attributes) included in the archive (and, hence, deleted because of "-m"), then it must be specified explicitly. For example: "testzip.dir [.testzip...]*.*". "-r testzip.dir" should also do it. Everything's complicated.
If you do try the replacement [.vms]vmszip.c, please report back any success or failure. If you lack a C compiler but wish to try it, please let me know, and I should be able to provide objects and executables.
It's not so much lacking a compiler that's the problem, it's having to support older sites (7.1 is the oldest). So I have been using the object modules that ship with the binary kit for 6.2, linking them on the oldest site we have, and then sending them out to the rest of the sites. I then do the same for >= 7.3-2 sites so that we also have a version supporting big files (for those sites that need such a thing). I could try the patched version on our development system, but if it works out, I'll need binaries for the older sites, too.
Great! The new vmszip.c works. So, all I need now is versions that work on our older sites (oh, and we're working on support for Itanium too, but nothing yet in production) and I'll be all set. Thanks!
Ben p.s. yeah, I noticed about the top-level directory not being removed, but I don't think that really matters in the few places where we use "-m"
Only because you didn't test it any better than I had. Sloppy code theft made it a minor disaster on non-ODS5-capable systems. The edition there now should be safer on older systems. (Checked out (at least a little) on V5.4 with VAX C V3.1-051.)
> It's not so much lacking a compiler that's the problem, it's having to > support older sites [...]
So, lacking _lots_ of compilers, then. Mr. Goatley generally makes the official VMS object and executable kits, and our antique collections differ. I should be able to do various VAX versions, including V5.5-2, V6.2, and V7.3. I recently upgraded my main Alpha from V7.3-2 to V8.3, so I don't have a V7.3-2 system right now. My IA64 systems are all at V8.3-1H1. If you can specify what you need but can't make yourself, I can tell you what I can't do.
Yes. In the absence of a version that runs on older systems, I was unable to test that. :/ Can you point me at a regression test suite I should be running? I couldn't find one in the ZIP30 kit I have, nor at the info-zip.org and sf.net sites.
OK, I need the following three binaries: - suitable for use on VMS/Alpha >=7.1 - suitable for use on VMS/Alpha >=7.3-2 (bigfile support) - suitable for use on VMS/Itanium >=8.3
> Can you point me at a regression test suite I should be running?
I wish.
> OK, I need the following three binaries: > - suitable for use on VMS/Alpha >=7.1 > - suitable for use on VMS/Alpha >=7.3-2 (bigfile support) > - suitable for use on VMS/Itanium >=8.3
How many compilers don't you have?
So far as I know, if you can build these programs on VMS V7.3-2, then you can use them on any newer VMS version with no loss of features. (Symbolic links on ODS5 don't actually work until V8.something, but a program built on V7.3-2 should handle them when it's run on, say, a V8.3 system.)
I know of no major differences between V8.3 and V8.3-1H1 on IA64, so a re-LINK should be possible (and may not be needed).
I don't (and won't) have any Alpha running anything earlier than V7.3-2, so I can't easily build anything on a V7.1 system. It's been a long time, and the details are fuzzy, but, as I recall, you may be able to build objects suitable for an older VMS version by defining the C macro __CRTL_VER to reflect the older version (and then doing a re-LINK on the target system). For example:
The MMS/MMK builders offer a CLEAN_EXE target to delete the executables, so the next build would re-LINK everything. The command procedure has a NOLINK option to avoid making them (on the source system), and a NOCOMPILE option to avoid trying to make new objects (on the target system). At the moment, with only V8.3 available, I can't try much myself.
Our VMS/Alpha development system is V8.3. It has compilers. Our current CC version on this system is V6.5-001.
Executables for software we have written are linked against libraries from the oldest VMS version we still support (currently V7.1) so we don't have to relink them on every system we deploy to. For third-party utilities such as Zip, we prefer to avoid the issue of having to compile for an older version of the OS by using binary kits from upstream supporting the older VMS version. If it is provided as object modules to be linked at installation time, we link it on the oldest site we support and then distribute the same executable to all sites. Failing that, we compile against old libraries, though that often requires some tweaking of upstream build procedures to make it work, and sometimes results in scrambling to find other libraries from V7.1 required by the third-party software. Thus, this is not our first choice.
We can ignore, for the moment, VMS/Itanium, as we do not yet have any sites deployed on these systems. We do have an Itanium development system with compilers on it, so if we had to, we could build Zip on that.
> [...] For third-party utilities such as Zip, we prefer to avoid the > issue of having to compile for an older version of the OS by using > binary kits from upstream supporting the older VMS version. [...]
That's fine, and I expect Zip 3.1, when it's released, to include this fix, and to be available in a form which you can use directly. However, while we're waiting for that glorious day, I believe that it makes more sense for you to try to build your own old-VMS-compatible kits than it does for me to try to do it. I don't seem to be any better equipped to do it, and you're definitely better equipped to test the results. You may be able to find another volunteer whose antique collection beats mine. comp.os.vms, perhaps?
I'm trying now to decide if I need to revisit this issue and get something together before our Spring release to address this, or if upstream is likely to produce what I need in that timeframe. How far off is 3.1 anyway? Weeks? Months? Years?
Logged
