This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Trundle, draghuram, eric.araujo, giampaolo.rodola, neologix, pitrou, r.david.murray, tarek, techtonik, vstinner
Date 2011-10-24.08:47:40
SpamBayes Score 3.1671568e-09
Marked as misclassified No
Message-id <1319445814.3298.2.camel@localhost.localdomain>
In-reply-to <CAH_1eM2N0jTcE692iYdFnF+WJsAQpFoJR20qU6EtHU7+RnyRsA@mail.gmail.com>
Content
> > "The solution? Let's remember that metadata changes are atomic. Rename is such a case."
> >
> 
> Hmmm.
> Is he referring to the "standard" rename? The blog doesn't evoke a
> specific function, but if it was the case, then why bother at all?

Standard rename (MoveFile) fails when the target exists, and that's
AFAICT the whole problem with it. MoveFileEx allows to overwrite the
target with MOVEFILE_REPLACE_EXISTING.

> By the way:
> """
>  - MoveFileEx() with MOVEFILE_REPLACE_EXISTING and
> MOVEFILE_WRITE_THROUGH flags: not atomic (eg. "If the file is to be
> moved to a different volume, the function simulates the move by using
> the CopyFile and DeleteFile functions."), version >= Windows 2000
> """
> 
> There's exactly the same limitation with the POSIX version (except
> that it'll fail with EXDEV instead of silently doing the copy+unlink).

If you don't specify the MOVEFILE_COPY_ALLOWED flag, MoveFileEx also
fails. I don't understand what Victor was trying to say.
History
Date User Action Args
2011-10-24 08:47:40pitrousetrecipients: + pitrou, vstinner, draghuram, techtonik, giampaolo.rodola, tarek, eric.araujo, r.david.murray, Trundle, neologix
2011-10-24 08:47:40pitroulinkissue8828 messages
2011-10-24 08:47:40pitroucreate