On 14 Feb 2007, at 08:30, Wolfgang Lux wrote:
Philippe Roussel wrote:
On 2007-02-12 20:45:48 +0100 Philippe Roussel
<[EMAIL PROTECTED]> wrote:
I couldn't find (with limited testing, I admit) something wrong
on my filesystem. GWorkspace (and Nautilus and mc) shows the
directory content without a glitch... I'll try to trace
NSDirectoryEnumerator when I'll have time.
In NSDirectoryEnumerator nextObject method line 2149,
returnFileName = [dir.path stringByAppendingPathComponent:
returnFileName];
returns dir.path if returnFileName starts with '~', it's really
easy to reproduce. I've read stringByAppendingPathComponent code
once and didn't get it but I'm sure you will figure it out easily.
Since no one seems to have answered so far, I had a look. It looks
like the
problem is in the line
unsigned root = rootOf(aString, aLength);
at the beginning of stringByAppendingPathComponent:, which seems
supposed to
skip any leading path separators at the beginning of aString, but
unfortunately
also skips a leading ~name component and also a leading X:
component. The former
is definitely wrong, and the latter is at least wrong on any *nix
system (don't
know whether Windows allows colons inside filenames).
So, I think stringByAppendingPathComponent: should not use rootOf,
but rather
check itself whether aString begins with any path separator
characters or
eventually a drive letter. However, the latter should be done only if
GSPathHandlingWindows() returns YES (using GSPathHandlingUnix()
would be okay
if pathHandling were set to "unix" by default on *nix systems).
Sorry for not getting back to you ... I modified svn-trunk yesterday
to check for the presence of a leading '~' in a path component and
refrain from calling rootOf() in that case.
Howerver, I'm not entirely sure what the correct behavior is ...
I'm fairly sure that we should just ignore (ie don't treat specially)
a '~' on all systems.
I'm also fairly sure we should just strip leading path separators
from the component on all systems.
However, what to do about a drive: prefix or a //host/share prefix is
less clear ...
Perhaps we should simply append the string and generate a debug log
about non-portable paths on unix,
and raise an exception if running under windows?
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
