[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSBundle -initWithPath: warning

From: Richard Frith-Macdonald
Subject: Re: NSBundle -initWithPath: warning
Date: Fri, 01 Apr 2005 11:54:20 +0100

On 2005-04-01 10:12:43 +0100 David Ayers <d.ayers@inode.at> wrote:

We could definitely use some some precise documentation of the relevant issues here in regard to what our path handling behavior should be.

Yes ... please could windows users investigate the work I've done in CVS and let us know how well it corresponds to actual windows behavior. I'm completely unfamiliar with UNC paths and haven't been able to find anything which looks like a *definitive* reference to their behavior on the web.

One person told me that '/' and '\' are completely interchangable on windows, so I coded to allow either in all places. Yet Alex Perez's last mail on this list seems to imply that ONLY '\\host\share' is valid for a UNC path. I've seen '\\host\share/directory/file' quoted on the web, but don't recall seeing '//host/share/directory/file' ... so if '//host/share' is NOT a UNC path, the current code should be ammended slightly.
There are probably other such issues that I'm not even aware of.

I mean, are we/should we be tracking the "current directory per drive"?
What does it mean to -changeCurrentDirectoryPath:
- in the simple case where the drives match (this seems trivial)
- when the drives don't match?

.... so that subsequent [obj writeToFile: @"D:file" atomically: YES] will "do the right thing"?

I'm inclined to think that we should just expect the windows SetCurrentDirectory() call to do what it wants with the path it is given. But it would be nice if we knew (and had the method documented) exactly how it does behave. I *think* that the function accepts both absolute and relative paths and handles drive specifications, but I don't know.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]