Rename unreliable on Windows

elef has asked for the wisdom of the Perl Monks concerning the following question:

Hi everyone, I've been trying to track down the cause of what seems to be a bug in ActivePerl and I think I've gotten as far as I can get. Maybe you can finish this for me.

My program needs to do quite a bit of file renaming, and the rename fails randomly with "Permission denied" about every 50th time. The bug doesn't seem to occur in Ubuntu, but it happens regularly on Win7 with ActivePerl.

Here's a script I wrote to provoke the bug:

#!/usr/bin/perl
use warnings;
use strict;


for (my $i = 1; $i <= 10000; $i++) {
    open (F1, ">:encoding(UTF-8)", "rename1.txt") or die "Can't open f
+ile1: $!";
    open (F2, ">:encoding(UTF-8)", "rename2.txt") or die "Can't open f
+ile2: $!";

    print F1 "File one";
    print F2 "File two";

    close F1;
    close F2;
    
    # unlink "rename2.txt";    # error occurs even if you unlink the f
+ile first, although less often
    
    rename ("rename1.txt", "rename2.txt") or die "Can't rename file: $
+!";
    print "loop $i done\n\n";
}
[download]

Comment on Rename unreliable on Windows Download Code

Replies are listed 'Best First'.
Re: Rename unreliable on Windows by Corion (Patriarch) on Apr 04, 2012 at 09:49 UTC
So why are you sure that "permission denied" is not actually the cause? Maybe you don't know that file locking is obligatory on Windows? If another application has opened a file in exclusive mode, renaming it will give you "permission denied" on Windows for example.	[reply]
Re^2: Rename unreliable on Windows by elef (Friar) on Apr 04, 2012 at 10:01 UTC
I didn't say that "permission denied" is not actually the cause... It could be, technically, in some roundabout way. The more relevant question is, what other application could have possibly opened the file in exclusive mode and why? I can't see an answer to that in the test script above, which fails for me with "Permission denied" somewhere between loop 1 and loop 900 every time.	[reply]
Re^3: Rename unreliable on Windows by Corion (Patriarch) on Apr 04, 2012 at 11:22 UTC
Maybe your virus scanner, maybe your backup application, maybe some other program. How would we know? think that the Sysinternals Tools have some program to show what programs hold a filehandle to a file, but I don't know. If in doubt, I would talk to the system administrator for the machines in question.	[reply]
Re^4: Rename unreliable on Windows by BrowserUk (Patriarch) on Apr 04, 2012 at 11:36 UTC
Re^4: Rename unreliable on Windows by elef (Friar) on Apr 04, 2012 at 11:44 UTC
Re^5: Rename unreliable on Windows by Corion (Patriarch) on Apr 04, 2012 at 11:53 UTC
Some notes below your chosen depth have not been shown here
Re^5: Rename unreliable on Windows by tobyink (Canon) on Apr 04, 2012 at 12:06 UTC
Some notes below your chosen depth have not been shown here
Re^5: Rename unreliable on Windows by Sinistral (Monsignor) on Apr 04, 2012 at 13:28 UTC
Re: Rename unreliable on Windows by tobyink (Canon) on Apr 04, 2012 at 10:19 UTC
Script runs fine for me; no crashes. Windows 2008 R2, Perl 5.12.4. I suspect you're triggering some sort of race condition in Windows' file locking, but even if I removed the print to STDOUT to try to speed things up, I wasn't able to trigger it. Sleeping for a few microseconds before calling `rename` might help. `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l]
Re^2: Rename unreliable on Windows by elef (Friar) on Apr 04, 2012 at 11:46 UTC
Thanks, I tested this with `usleep 50000;` but it didn't help. See resolution above (backup software was locking files).	[reply] [d/l]
Re^3: Rename unreliable on Windows by Anonymous Monk on Apr 04, 2012 at 12:54 UTC
Good catch. Points out that any operation that might possibly fail, especially when run on end-user machines (that are commonly less-privileged than the [foolishly, too privileged] developer machines), should trap for runtime errors with `eval` or otherwise, and be prepared to handle them plausibly.	[reply]