discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GWorkspace mdextractor problem


From: Richard Frith-Macdonald
Subject: Re: GWorkspace mdextractor problem
Date: Wed, 14 Feb 2007 11:27:25 +0000


On 14 Feb 2007, at 08:30, Wolfgang Lux wrote:

Philippe Roussel wrote:

On 2007-02-12 20:45:48 +0100 Philippe Roussel <p.o.roussel@free.fr> 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?





reply via email to

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