On Mon, 31 Jan 2005 10:06:24 +0100, "Jan E. Schotsman" <email@hidden>
wrote:
>
> On 31-jan-05, at 0:26, daniel wrote:
>
>> It looks like this return code is properly documented in the
>> FindFolder documentation but not in the FSFindFolder equivalent:
>>
>> The result code dupFNErr indicates that a file has been found instead
>> of a folder.
>>
>> Note that this could be caused by either the indicated folder or any
>> parent of the indicated folder being a file instead of a folder.
>> Though for the Trash it's usually a pretty shallow search.
>>
>> By the way, it's probably better not to pass kUserDomain to
>> FindFolder. Usually you are looking for the Trash because you want to
>> throw something away, and in that case, you should ask for the trash
>> by volume. If the item you're throwing away is on the user's disk,
>> then will happen to get the trash folder in the user's home directory.
>
> I just want to check if the file is in the trash (same reasoning
> applies of course).
> Anyway, this return code means the user's file system is corrupt, right?
No, it means that one of the elements of a path isn't a directory. For
example let's say you have a path </Users/Bob/Documents/Foobar/Readme.txt>.
If <Foobar> is a file instead of a directory then you can't open
<Readme.txt>.
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
