[Python-ideas] Implementation of shutil.move
aquavitae69 at gmail.com
Fri Aug 12 19:35:41 CEST 2011
If the kernel doesn't allow file locking then I don't see any way that a
locking context manager will be possible, but it should still be possible to
safely move files using link and unlink. Maybe the other problem functions
can be dealt with individually in a similar way?
On Aug 12, 2011 6:57 PM, "Christian Heimes" <lists at cheimes.de> wrote:
> Am 12.08.2011 18:37, schrieb Masklinn:
>> On 2011-08-12, at 17:03 , Christian Heimes wrote:
>>> Am 12.08.2011 16:55, schrieb Masklinn:
>>>> On 2011-08-12, at 16:48 , David Townshend wrote:
>>>>> My understanding of os.O_EXCL is that it locks the file from changes
>>>>> other process.
>>>> That, *could* be O_EXLOCK, but I'm not too sure.
>>>> O_EXCL does not do anything in and of itself, it fails the file opening
if combined with O_CREAT. That's it (from man 2 open):
>>>> O_EXCL error if O_CREAT and the file exists
>>> The man page open(2) doesn't mention O_EXLOCK. It must belong to another
>>> low level function.
>> Nope, got it from open(2), but it's apparently a bsd extension:
>> This information (that it's an extension) is present in the OpenBSD
open(2) page, but I checked it on an OSX machine where it's not specified.
>> It's an atomic `flock(fd, LOCK_EX)` (or LOCK_SH) built into open(2) to
avoid the unlocked open hole between the open(2) and flock(2) calls.
> Ah, I've checked the open(2) man page on Linux. Should have mentioned
> the OS ... sorry, too.
> Anyway flock()s are only advisory (cooperative) locks and not mandatory
> locks. Although some Unices have support for mandatory locks, they can
> be circumvented with unlink().
> Python-ideas mailing list
> Python-ideas at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas