John E. Malmberg wrote:
One of the reasons that the lib/cpanplus/t/00_cpanplus-internals-utils.t
is failing is that it is attempting to rename a directory.
That is failing on VMS for two reasons.
1. The C<rename()> in the VMS CRTL on 8.3 by default is not renaming
directories (Behavior varies with VMS version).
2. The old directory is created with out delete access.
This exposes an inconsistency in Perl on VMS, where C<unlink()> will
follow UNIX conventions and delete a file as long as it has write access
to the parent directory, and C<rename()> which currently follows VMS rules.
It really should be a case where C<rename()> and C<unlink()> are both
either following the VMS protection rules or both following UNIX rules.
Changing unlink() to follow VMS protection rules might result in
breaking existing applications. So could a change in rename() to follow
UNIX rules.
C<rename> also needs some work so that the when Perl on VMS is running
in a POSIX/UNIX mode, it makes sure that only one version of the file
is left after the rename completes.
So should C<rename()> always follow UNIX protection conventions, or
should that be another feature?
Should the same thing be done for C<unlink()>
Another interesting wrinkle on UNIX is where foo1 and foo2 are both
directories:
rename('foo1', 'foo2') replaces foo2 with foo1.
rename('foo1', 'foo2/') also replaces foo2 with foo1.
This is counter to the shell mv command which in the second syntax for
the filename results in the foo1 directory tree being placed under foo2.
VMS users would also expect that behavior, especially with VMS syntax.
-John
[EMAIL PROTECTED]
Personal Opinion Only
