Re^3: Rename unreliable on Windows

[Corion]

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.

[BrowserUk]

think that the Sysinternals Tools have some program to show what programs hold a filehandle to a file,

Yes. it is called handle.exe:

C:\test>handle /?

Handle v3.42
Copyright (C) 1997-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

usage: handle [[-a [-l]] [-u] | [-c <handle> [-y]] | [-s]] [-p <proces
+s>|<pid>] [name]
  -a      Dump all handle information.
  -l      Just show pagefile-backed section handles.
  -c      Closes the specified handle (interpreted as a hexadecimal nu
+mber).
          You must specify the process by its PID.
          WARNING: Closing handles can cause application or system ins
+tability.
  -y      Don't prompt for close handle confirmation.
  -s      Print count of each type of handle open.
  -u      Show the owning user name when searching for handles.
  -p      Dump handles belonging to process (partial name accepted).
  name    Search for handles to objects with <name> (fragment accepted
+).

No arguments will dump all file references.

[elef]

Thanks for that one!
It was indeed my backup sw (WD anywhere backup). After disabling it, the test script runs to 10000 loops without errors.

Followup question: why does this happen and is there an easy workaround (apart from disabling the backup sw)? I mean, I don't think I've had problems with deleting or modifying files, only renaming... And I don't think I've had issues outside of perl.

[Corion]

This is how Windows as an operating system works. A file cannot be renamed while it is held open.

A good backup software would request the backup privilege, and use the Windows Backup API. But even then, I'm not sure whether that would allow renaming a file while it is held open.

[tye]

elef should file a bug report / complaint against this backup software. It doesn't even have to use the Backup API. It can simply specify full sharing when opening the file. Simply add in the FILE_SHARE_DELETE bit (which also allows renaming) when opening the file (though, the Backup API likely provides other benefits).

[tobyink]

is there an easy workaround (apart from disabling the backup sw)?

You could just keep trying to rename it...

1 until rename $file1, $file2;

Of course, if a file can genuinely never be renamed, this will cause your script to keep trying forever. Better to limit to a finite number of attempts at renaming.

my $attempts;
while (not rename $file1, $file2)
{
  $attempts++;
  die "Could not rename file: $!" if $attempts > 7;
  sleep $attempts;
}

[MidLifeXis]

You could also throw it into a queue of items "to deal with later".

[elef]

Thanks. Hoping that copying is more robust than renaming, I tried this:


    unlink "rename2.txt" or die "Can't delete file: $!";
    copy ("rename1.txt", "rename2.txt") or die "Can't copy file: $!";
    unlink "rename1.txt" or die "Can't delete file: $!";


Errors became less frequent, but they're still there. I'll try your suggestion. I really like the idea of sleeping increasing intervals between attempts, too.

-------------------
Edit: did the test, and the solution works. I also added some reporting to see how many extra attempts are needed for the renamings to succeed. The second attempt was sufficient every time, and it was needed ~50 times before the script got to 10000 loops. I'll implement this with 5 attempts max (just in case the backup sw spends more time on larger files) and forget about the issue. Thanks.

[Sinistral]

One of the solutions that you could use in conjunction with your script is Unlocker. Although the screen shots highlight the GUI, there's also a command line version. If you used that, your script should then be able to do the rename.