> -----Original Message-----
> From: Craig A. Berry [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 01, 2004 9:00 AM
> To: John E. Malmberg
> Cc: [EMAIL PROTECTED]
> Subject: Re: Correct way to delete file(s) on OpenVMS?
> 
> At 12:35 AM -0400 9/1/04, John E. Malmberg wrote:
> >Craig A. Berry wrote:
> >
> >>There's also a configure-time option in Perl to delete all versions
> >>of a file, but it's currently not working.  John Malmberg submitted a
> >>patch that makes it work, but I'm afraid I have sat on it for a
> >>while, though I have not forgotten it and hope to get to it soon.
> >
> >IIRC: As part of that patch, it allows a configure time option to use
> unlink() instead of remove().
> >
> >What unlink() does is removes a link to a file, and if it is removing the
> last link to a file, the file is deleted.
> >
> >With remove(), the file is removed, and the links become orphaned if I
> understand the UNIX specifications correctly.  That is why unlink() may be
> preferred to remove().
> 
> The POSIX standard says,
> 
> "The remove() function causes the file named by the pathname pointed to by
> path to be no longer accessible by that name. A subsequent attempt to open
> that file using that name will fail, unless it is created anew.
> 
>  If path does not name a directory, remove(path) is equivalent to
> unlink(path).
> 
>  If path names a directory, remove(path) is equivalent to rmdir(path)."
> 
> That standard definition is available here:
> 
> http://www.opengroup.org/onlinepubs/007908799/xsh/remove.html
> 
> 

By the above definition, remove(), to be POSIX compliant, would have to remove
all versions of a VMS file if called without an explicit version number.
Without that, it fails the "A subsequent attempt to open that file using that
name will fail, unless it is created anew" condition.

As someone pointed out, there is a logical (?) to set just this behavior.

> --
> ________________________________________
> Craig A. Berry
> mailto:[EMAIL PROTECTED]
> 
> "... getting out of a sonnet is much more
>  difficult than getting in."
>                  Brad Leithauser

Reply via email to