ACL_SCRUB for Alpha

[Hoff]

Based on what I'm finding in the acl_scrub source code, there are definitely some nasty bugs here, and bugs that the newer compiler is finding. I'd not choose to run this particular code -- whether ported or translated -- without a whole lot of testing, based on what I see this source code doing.

The current code is also ODS-2 only, and that may or may not matter for this case. It's looking at file headers all over the place.

If somebody has a target practice configuration and particularly one that they don't mind stomping on, please contact me offline.

[Dean McGorrill]

For removing aces, I've usually taken a file
with none. eg create an empty file say
dummy.dat with no ace/acl's then do a..

$ set file/acl/like=dummy.dat *.*

or disk:[*...]*.*;* if you want them all
gone

Dean

[Robert Gezelter]

Zeni,

Reading today's posts, I should perhaps clarify some things about binary translators in general, more for the sake of leaving a record for others who read this thread in the future.

I have not had the chance to review the sources for ACL_SCRUB as Hoff has apparently had the chance to do (instead spent the day traveling between meetings stuck in traffic caused by some severe thunderstorms in the NYC area, but I digress).

Binary translators do very well at translating correct code. This is particularly useful in situations where the sources are correct, but
- are written using otherwise obsolescent language versions (e.g., VAX C)
- where sources are incomplete
- large numbers of clerical edits must be made to reflect the changed architecture.

I firmly advocate the use of translators as strategic tools, but they are not a panacea. If the code has bugs, binary translators are bug-for-bug compatible. Additionally, since translators are almost invariably used in concert with new OS versions, there is always the potential for marginally legal uses of the APIs to not function as intended.

As always, caution is advised.

If I have been unclear, please feel free to follow up this posting. Also, please feel free to contact me directly offline.

- Bob Gezelter, http://www.rlgsc.com

[Zeni B. Schleter]

For the Cautionary notes of Hoff and Bob Gezelter, duly noted.

As a review, I am trying to remove obsolete ACEs across a wide number of disks (possibly). The reason for the obsolete ACEs are because of accounts that were removed or identifiers that were removed. In this thread, the removal of unused accounts and identifiers was brought into question but that was not the point of the thread.

The latest rendition of OMSVA was delivered with OpenVMS v7.3-1. I successfully used that product to run ACL_SCRUB on a OpenVMS v7.3-2 Alpha. I had to use the /INTERPRET switch. So this does work but with the cautionary notes, I don't know that I should. I will spend some time going over what Wim suggested to get a clean compile and what the code really does.

Thanks to All.

[Hoff]

I've a ported and compiling and linking version of ACL_SCRUB, FWIW; updated to V8.3. It is not debugged (nor am I going to spend much time on same right now due to other work in the queue), though I've updated the code to recognize all current ACE types, and to lock out the ACE delete path unless a (newly-added) /DELETE qualifier is specified to allow said ACE deletion.

Here's the current source port...

http://64.223.189.234/node/426

[Wim Van den Wyngaert]

Nice job Hoff ! /DEL was indeed missing.
A program that removes things should always have that option.

Wim

[Zeni B. Schleter]

I reopened the thread to update the points.
I have downloaded the modifed code from Hoff's website and will look through the results and test on a test host. Display.C had a // at the beginning of a line that caused an error when compiled with a /STANDARD=VAXC but without the VAXC qualifier there were a lot of warning messages about variant_union and variant_struct.

But , thanks, that is way more effort than I expected.

[Hoff]

An updated URL for the download location of the ACL_SCRUB tool:

http://labs.hoffmanlabs.com/node/426