[Guido] > ... > I certainly wouldn't want to try to emulate the Windows semantics on > Unix. However, I think that emulating the correct Posix semantics on > Windows is not possible either. Neither is it desirable: Windows isn't POSIX, and Windows users would be appalled if os.rename() could silently destroy files. If such a function needs to exist, create a new cowboy_unix_tricks module instead <wink>. This has never been a problem for me because I always check to see whether the target file exists before using os.rename(), and do something else if it does. I understand that's vulnerable to races, but nobody asked whether I cared about that <wink>. > The Posix rename() call guarantees that it is atomic: there is no > point in time where the file doesn't exist at all (and a system or > program crash can't delete the file). I wouldn't know how to do > that in Windows -- the straightforward version > > if os.path.exists(target): > os.unlink(target) > os.rename(source, target) > > leaves a vulnerability open where the target doesn't exist and if at > that point the system crashes or the program is killed, you lose the > target. More obvious, it also fails if target simply exists and is open (you can't unlink an open file on Windows). Nevertheless, you can do this renaming safely on Windows, via doing the right system magic to make rename happen at reboot time before Windows actually starts. But I'm not sure Skip's client would want to reboot each time Python did a file rename <wink>. > I would prefer to document the difference so applications can decide > how to deal with this. Yup!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4