1

I'm building a script that renames some files to determine if the file is locked or not. The script does the following on every file in a given directory recursively.

try: 
    os.rename(source, temp)
    os.rename(temp, source)
except OSError as e:
    print 'exception'

My question is should there be a time.sleep(1) between the os.rename() calls? I'm worried the file might not be renamed by the time the other os.rename() call takes place, but I want it to run as fast as possible.

Thanks for any help.

Lucas David
  • 21
  • 3
  • The next line is not executed before the first call returns. You're not calling an daemonized external script, so I don't think you need to worry about sleeping between calls. Have you seen some behavior that makes you feel like the `os.rename` call is non-blocking? – inspectorG4dget Aug 22 '13 at 18:57
  • 1
    What's the purpose of renaming a file to temp and then back? – NPE Aug 22 '13 at 18:57
  • You might want to take a look at http://docs.python.org/3.4/library/msvcrt.html for Windows and http://docs.python.org/3.4/library/fcntl.html for Unix instead. – Lennart Regebro Aug 22 '13 at 19:05
  • 1
    There should _never_ be a `time.sleep(1)` to solve a race condition, except as an absolute last resort. If there's any possibility the first `rename` might not have finished immediately, there's also a possibility it might not have finished a second later. – abarnert Aug 22 '13 at 19:05
  • @NPE: The purpose is to see if the files is locked, ie open for writing by another process It will only work on Windows, I believe. – Lennart Regebro Aug 22 '13 at 19:06
  • @LennartRegebro: I hope that's not a common idiom (given that it's potentially destructive). – NPE Aug 22 '13 at 19:09
  • 1
    @LennartRegebro: Actually, it doesn't really work on Windows. A `rename` checks `FILE_SHARE_DELETE`, not `FILE_SHARE_WRITE`. While these _often_ go together, they don't _have to_. (It actually _would_ work on POSIX systems that have mandatory locks, if anyone used them… but nobody does, and besides, there are better ways to check anyway.) – abarnert Aug 22 '13 at 19:09
  • 1
    Also take a look at this question: http://stackoverflow.com/questions/13371444/python-check-file-is-locked, there are easier ways to handle your issue. – Patrick Collins Aug 22 '13 at 19:01
  • 1
    The big question is: [Why do you want to know why the files are locked?](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) 90% of the time when people ask this, it's not really what they want. For example, if you're trying to filter the files before opening them, don't do that, just `try` opening them. If you think this is a first step toward building a `handle`- or `openfiles`- o `lsof`-like tool, it's not; you need to query the kernel objects. And so on. – abarnert Aug 22 '13 at 19:16
  • Another question is, why are these files locked? If other processes are using files in this directory, they could be confused by the temporary renames (for instance, unable to find a file that should be there or creating a new file while the real one happens to be renamed). – tdelaney Aug 22 '13 at 19:45

2 Answers2

7

No, because these commands are all blocking.

Uku Loskit
  • 40,868
  • 9
  • 92
  • 93
2

The second os.rename() will be call only when the first will have finished (principle of blocking command). So you don't have to worry about the time of execution.

Maxime Lorant
  • 34,607
  • 19
  • 87
  • 97