http://www.perlmonks.org?node_id=963392

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"; }

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.

      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.

        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.

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'
      Thanks, I tested this with usleep 50000; but it didn't help. See resolution above (backup software was locking files).
        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.