Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: A DWIM too far?

by Abigail-II (Bishop)
on Jun 19, 2004 at 05:07 UTC ( #368117=note: print w/ replies, xml ) Need Help??


in reply to Re^2: A DWIM too far?
in thread A DWIM too far?

As is, the behaviour makes it impossible to safely rename a file.

That depends on your definition of "safely". The other possible default (not renaming if the target file exists), also prevents "safely" renaming a file. Because that will prevent the to-be-renamed file to be renamed. So that's also "unsafe".

You should also consider what should happen in the following situation:

$ touch file $ ln -s target link $ rename file link
Rename or not?

Note that if you want to do a "safe" rename, you can do so, although it involves a copy:

my ($f1, $f2); if (sysopen $f1, "new", O_WRONLY | O_CREAT | O_EXCL) { open $f2 => "old" or die; print $f1 <$fh2>; close $f1 or die; unlink "old" or die; }
You can test existance before issuing the rename, but in any multi-tasking environment there is always the possibility that the target file will be created between the test for existance and the rename.
Frankly, I don't get your point. What are you trying to say here? That the rename is making you lose data? That I disagree with. Suppose you are multi-tasking, one threads wants to create a file "new", and another thread wants to move "old" to "new", but you want to end up with both the data that is in "old", and with the data that would be placed in "new" by the other thread. Suppose you would have a 'rename' that doesn't rename if there is already a "new" file. Does that win you anything? Not if the renaming process thread goes first. Then "old" will be renamed to "new", and then wiped out by the other thread that's creating "new". Rename is not to blame in this scenario - the programmer is to blame by not syncronizing two threads that modify the same resource.
This rates up there with non-exlusive-opens-by-default and cooperative locking as remnant bahaviours of a bygone era that should have been superceded long ago.
Well, you can always change your system calls. Oh, wait, you can't.

Abigail


Comment on Re: A DWIM too far?
Select or Download Code
Re^2: A DWIM too far?
by hv (Parson) on Jun 19, 2004 at 13:57 UTC
    Note that if you want to do a "safe" rename, you can do so, although it involves a copy

    I may have missed something, but I think it can be done much more easily like this:

    sub rename_i { my($src, $dest) = @_; link($src, $dest) or die "Can't link $src to $dest: $!"; unlink($src) or die "Can't unlink $src: $!"; }

    Hugo

      Well, yes, of course. And I should have know, because that's classical idiom. I'm just going to blame YAPC. 12 hours of sleep in 3 nights.

      Abigail (Conferences and Perlmonks don't mix)

      That may not work for directories.

      But I think that idiom justifies Unix's choice of rename behavior. If rename failed when a new file already exists, there isn't good way to code a rename-that-overwrites.

Re^2: A DWIM too far?
by BrowserUk (Pope) on Jun 19, 2004 at 16:12 UTC
    Well, you can always change your system calls. Oh, wait, you can't.

    Of course I could--but I don't need to :)


    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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://368117]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2014-08-01 23:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (52 votes), past polls