Re^2: A DWIM too far?

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:

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.
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

Comment on Re^2: A DWIM too far?

Replies are listed 'Best First'.
Re^3: A DWIM too far? (POSIX) by tye (Sage) on Jun 18, 2004 at 19:02 UTC
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]
Re^4: A DWIM too far? (POSIX) by BrowserUk (Patriarch) on Jun 18, 2004 at 19:25 UTC
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]


"be consistent"
	PerlMonks