Re: rmdir('/unix_path/to/dir') not working with 5.18.1?

[email protected] ("Craig A. Berry") Sat, 08 Mar 2014 12:38:46 -0600
Newsgroups perl.vmsperl
Message-ID <[email protected]>
On Mar 7, 2014, at 6:49 PM, John E. Malmberg =
<[email protected]> wrote:

> On 3/7/2014 8:18 AM, Craig A. Berry wrote:
>>=20
>> On Feb 26, 2014, at 11:35 PM, John E. Malmberg
>> <[email protected]> wrote:
>>=20
>>> On 2/25/2014 7:02 PM, Craig A. Berry wrote:
>>>>=20
>>>> On Feb 24, 2014, at 11:33 PM, John E. Malmberg
>>>> <[email protected]> wrote:
>>>=20
>>>>> I can not seem to do a rmdir() of an absolute or relative Unix
>>>>> path  with Perl 5.18.1.
>>>>=20
>>>> It works unless DECC$FILENAME_UNIX_REPORT is defined. That's not
>>>> particularly well tested and you definitely found a bug. If
>>>> that's defined, when rmdir calls the internal stat routine, which
>>>> calls fileify, then 'abc/xyz' becomes 'abc/xyz.DIR;1'.
>>>=20
>>> If fileify is converting 'abc/xyz' to 'abc/xyz.DIR;1', that is a
>>> bug that will break a lot of stuff.  With the DECC$EFS_CHARSET
>>> enabled, that should never happen anywhere.
>>>=20
>>> Not only should the ;1 not be present, the ".DIR" should not be
>>> present either.
>>=20
>> I think we've had this discussion before.  Fileify really has to
>> append the .DIR;1 because there are too many things, rmdir being one
>> of them, that simply cannot operate on a directory spec but only on a
>> directory file. That's really the point of fileify and we wouldn't
>> call it if we didn't have to
>=20
> In a UNIX format filespecification, the .DIR or .DIR;1 is always a =
bug.

I suppose that's true if the user asked for Unix report mode and if we =
were reporting filespecs to the user.  None of that has anything to do =
with the purpose of fileify, which is to provide the VMS-native filename =
of a directory so that it can be operated on by native services.  Note =
in particular that readdir omits the extension and version when Unix =
report is in effect, so nothing should see the .DIR;1 that doesn't =
specifically ask for it by calling fileify.

All uses of fileify in the core are in [.vms]vms.c.  In fact there are =
only three uses:

1.) Perl_flex_stat_int.  This stores an expanded filename in native =
format in an extended version of the stat structure so that its callers =
have it available if needed, and if the file is a directory, it's =
fileified.

2.) do_rmdir.  This is ultimately based on SYS$ERASE.  The format in =
which filenames are reported to the user is irrelevant; SYS$ERASE still =
has to have the .DIR extension to be able to delete a directory. =20

3.) Perl_rename. This is based on LIB$RENAME_FILE.  What I said about =
SYS$ERASE in #2 applies here too.

That's it.  And in fact #2 seldom kicks in as rmdir normally gets the =
pre-fileified spec from stat() and only calls fileify directly if the =
stat failed.

It may be that we could do a vmsify first and then fileify, but I think =
I tried that once and ran into trouble.  It may be that we could =
refactor some of this code so that fileify simply becomes a flag passed =
to int_tovmsspec or int_rmsexpand.  There is certainly a great deal of =
redundant processing in these routines.  But changing fileify to not do =
what it was designed to do would break (at least) rmdir and rename and =
probably other things that depend on a native fileified spec in the stat =
buffer.


> Neither DECC$EFS_CHARSET nor DECC$FILENAME_UNIX_REPORT has any impact
>> on this.  So I've changed vmsify in Perl to do exactly the same thing
>> the CRTL does.  Well, not exactly because the CRTL honors
>> DECC$FILENAME_UNIX_NO_VERSION by escaping the semicolon even if the
>> version spec is valid:
>=20
> Then Perl should also be using that feature.
>=20
>> $ DEFINE DECC$FILENAME_UNIX_NO_VERSION 1
>> $ mcr []to_vms
>> abc/xyz.dat;32767 Translating: abc/xyz.dat;32767 file:
>> [.ABC]XYZ.DAT^;32767 1 files found
>>=20
>> I haven't (yet) made Perl do this.  It wouldn't be hard to do, but
>> I'm a little skeptical about trying to support the whole wilderness
>> of feature logicals.
>=20
> It is something that IMHO is critical to add, and I encountered this =
in the test harness for GNU make and had to modify the code to work =
around it.

OK, I'll add it. =20
________________________________________
Craig A. Berry
mailto:[email protected]

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser