At 5:22 PM -0400 9/4/03, John Peacock wrote: >>@[.VMS]Test.Com ".exe" "" >>%COPY-E-OPENOUT, error opening DKA0:[UTILS.PERL.T]PERL.; as output >>-RMS-E-PRV, insufficient privilege or file protection violation >>%COPY-W-NOTCOPIED, DKA0:[UTILS.PERL]PERL.EXE;1 not copied > >This even though I am still 'set proc/priv=all'.
That's not just a big hammer, it's potentially a wrecking ball. I confess to using it myself sometimes, but it's much better to work out the correct ownership and protection issues if at all possible. >I see that [.vms]test.com removes most priveledges before running, which of course >means I cannot create any files in the [.t] directory... > >I'm guessing that I have to build/test Perl as a non-priviledged user, so that I own >the directories/files??? Either the account you test from has to own the files, or the protections have to be set such that other users can create files under [.t]. Note that ownership of the files in your case may depend on ownership inherited from the directory DKA0:[000000]UTILS.DIR. If you create the files in such a way that they are owned by one account and later build from another, privileged, account, things will work up until test.com downgrades privileges. I still think downgrading privileges is the right way to go for the test suite, but it does require a consistent view of ownership and protection throughout the unpack, configure, build, and test sequence. More than likely the correct solution for you would be something like: $ create/directory dka0:[utils.jp_perltest] $ set file dka0:[utils]jp_perltest.dir/owner=jpeacock Then create your test builds under that directory tree. There would be no reason for elevated privileges at any stage if you make yourself the owner from the get-go. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
