in reply to A DWIM too far?

Oh yeah... This is on a par with unlink() being the equivalent of unix  rm -f (i.e. "don't ask questions, just delete the file(s)!") -- and when you combine this with an all-too-common misunderstanding about unix file permissions, you really see how unix gets its reputation as being "not for the feeble-minded or faint-hearted".

The misunderstanding involves setting individual file permissions to "read-only", and thinking that this protects the file from being deleted. It doesn't. The file is protected from having its contents altered by being opened for write access, and that's it.

Now, if the directory containing the file is also set for "read-only" access, then the file is safe, but so long as there is write access on the directory, the file can be deleted (or another file can be renamed to displace/obliterate it).

The default behavior of unix "rm" involves always asking for interactive confirmation before deleting a file that is set for read-only access, but "rm -f" is always available to bypass that safeguard (e.g. when running in a script or makefile), and this is what Perl's "unlink()" does.

I'm not saying it's good or bad for it to be this way. Just like a chainsaw is not intrinsically good or bad... It simply requires care and respect.

Replies are listed 'Best First'.
Re^2: A DWIM too far?
by BrowserUk (Patriarch) on Jun 18, 2004 at 02:57 UTC

    I agree, though I was less concerned with the behaviour of system utilities. I can always adapt those using aliases or bat files or whatever.

    And I'm rarely in favour of "do you really want to do what you have just asked me to do" prompts, especially the accursed pop-up variety.

    But when it came to Perl overriding the standard behaviour of a usually safe (on my OS) API to provide compatibility with a potentially destructive (and IMO, questionable) behaviour of a.n.other OS, let's just say it didn't comply with my idea of 'least surprise'.

    Perhaps the critisisms of "who reads the documentation anyway" are valid here. I never read the docs for rename simply because I didn't think I needed to. I just cannot see the circumstance where rename failing because the target file exited would ever be a burden. If I know that the file might exist and that I want to overwrite it, then I just attempt to delete it first.

    I realise that this would be non-atomic. That there is a chance in a multi-tasking system that another process could re-create the deleted file between the delete and the rename, and the rename would then again fail. But so what? I cannot percieve of any circumstance where the unix behaviour would be the "right thing" in this situation.

    I'm not sure if the unix destructive rename is atomic at the syscall level or not, but there are two possiblilities:

    1. The delete/rename is atomic.

      If true, then once my application has renamed the file, then the other application that was trying to create the file will either

      • Succeed and overwrite my newly renamed data.
      • Fail if he bothered to use an deny-shared open mode.
    2. The delete/rename is not atomic.

      If true, the other app could potentially re-create the deleted file prior to the rename? What then? Does the rename then fail?

    I realise that well-written apps that use sensible choices of share flags and/or file permissions can work around this, but it still seems a strange choice of default behaviour.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
[reply]

      FYI, POSIX rename() is atomic. Perl's rename is based on POSIX rename() but Perl may use a different API when compiled on a system that doesn't (appear to) have POSIX rename() (hence the weasel words about it perhaps not silently clobbering). Therefore, Perl's rename will not be atomic on some non-POSIX systems.

      I can't think of any APIs that Perl has taken from Win32. Where a Perl API matches a Win32 API it is almost always because the Win32 API was made to match the POSIX (or pre-POSIX) API. While I concur with your preference to "use the safer of the two" when selecting, I'd certainly be more surprised to find Perl using a Win32 API that conflicts with a POSIX API.

      BTW, I wish Perl's system() had asynchronous launching built in so that could be done portably. It is rather ironic that asynchronous launching is built into the under-the-covers API that Perl uses but it doesn't expose this nice feature in the language -- well, on nearly OS/2 systems (including Win32) you can use system(1,...) to launch a command into the background, but that isn't portable and making that API choice portable poses problems on less OS/2ish systems like Unix where commands are passed a list of arguments instead of a command line.

      - tye        

[reply]

        I suppose I shouldn't have been surprised that Perl would opt for the POSIX api, even emulating it where the native was (by my definition:) better--but I was.

        What still surprises me is that POSIX still specifies a less useful default behaviour.

        Thanks for telling me about the system( 1, ... ) trick. Is that documented somewhere?

        I've been using  use threads qw[async]; async{ system ...; }; for that for a while now, but that is nice if not portable.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
[reply]
[d/l]
[select]

In Section Meditations