From: Richard Frith-Macdonald <richard@brainstorm.co.uk>
Date: Mon Sep 16, 2002 03:43:33 PM Europe/London
To: Roland Schwingel <Roland.Schwingel@onevision.de>
Subject: Re: -[NSData writeToFile:atomically:] Bug introduced in 1.5.0
On Monday, September 16, 2002, at 01:38 PM, Roland Schwingel wrote:
Hi....
Im am still migrating sources... And I found I bug which was
(when diffing with base-1.4.0) introduced in base-1.5.0.
On Windows NSDatas -writeToFile:<path> atomically:YES is no longer
working.
After creating the file it tries to rename() new File to old File. But
it can't because
old file is still present....
If you go to line 907: you will find this:
if ([mgr fileExistsAtPath: path])
{
att = [[mgr fileAttributesAtPath: path
traverseLink: YES] mutableCopy];
IF_NO_GC(TEST_AUTORELEASE(att));
}
In 1.4.0 the source looked like this:
if ([mgr fileExistsAtPath: path])
{
att = [[mgr fileAttributesAtPath: path
traverseLink: YES] mutableCopy];
IF_NO_GC(TEST_AUTORELEASE(att));
[mgr removeFileAtPath: path handler: nil];
}
mgr is declared previously. And indeed with 1.5.0 I am getting an
errormessage regarding this problem to be
not able to rename the file.
Thanks for the report.
The code in 1.4.0 was wrong ... deleting the file before creating the
replacement
leaves a (tiny) window during which the file does not exist ... so the
operation
was not atomic as it should have been.
The order of operation in 1.5.0 is correct.
However, it seems you have spotted a bug in windoze ... the
implementation of
rename() does not support replacement of an existing file at the
destination
as the posix standard explicitly says it should.
I've modified the code so that it uses a windoze specific call that
should do
the replacement.