Re: Serious bug in NSFileManager fileExistsAtPath:?
Re: Serious bug in NSFileManager fileExistsAtPath:?
- Subject: Re: Serious bug in NSFileManager fileExistsAtPath:?
- From: j o a r <email@hidden>
- Date: Sat, 21 May 2005 16:15:23 +0200
On 21 maj 2005, at 15.50, Stéphane Sudre wrote:
Which result shall be returned by the NSFileManager
fileExistsAtPath: API when the file is 0 bytes?
I'm guessing that the problem you mention isn't related to the size
of the file, but rather to which fork that holds the data.
From what I'm seeing, when a file is 0 bytes long (this is due to
the fact that it was a Resource fork archived in a zip archive and
then decompressed using OpenUp (or another one)), the result is NO.
So, it doesn't have a data fork at all?
This leads to the point where the API is saying NO when the file is
really here and displayed both by the Finder and the shell.
lstat is returning ENOENT ( /* No such file or directory */ )
This is happening from 10.2.8 to 10.4.1.
Any idea on why an Unix OS is blind when the file is 0 bytes long.
I'm not very surprised that it might report incorrectly if there is
no data fork. Perhaps you could verify if that's the case or not.
Definitively worth a bug report regardless of the outcome.
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden