Re: rmdir('/unix_path/to/dir') not working with 5.18.1?
"Craig A. Berry" <[email protected]> Sat, 08 Mar 2014 12:38:46 -0600
| Newsgroups | gmane.comp.lang.perl.ports.vms |
|---|---|
| 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