bugGNUstep - Bugs: bug #32094, [NSString...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #32094: [NSString stringByStandardizingPath] doesn't work well with any path beginning with extra slashes

Submitted by:  Sergei Golovin <svg>
Submitted on:  Tue 11 Jan 2011 07:35:25 AM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Wed 12 Jan 2011 10:54:51 AM UTC, comment #7:

> Suppose we have got the path string "//path/tofile/" from an external source.
> Is it an UNC path as a general rule?


Yes ... that's what our documentation says.

> I think somebody who wants standardize that path expects to get "/path/tofile"


If you want that behavior, then you should set the library to use strict 'unix' paths as stated in our NSString documentation. That might make sense if you are writing unix-only code.

But GNUstep is a cross-platform development framework ... and it's vastly more likely in general (ie not just the unix world) that //xxx/yyy/ is a well formed UNC path than a poorly formed unix path, so you haven't said anything which suggests that the current behavior is wrong.

Richard Frith-Macdonald <CaS>
Project Member
Wed 12 Jan 2011 10:42:03 AM UTC, comment #6:

Suppose we have got the path string "//path/tofile/" from an external source. Is it an UNC path as a general rule?
I think somebody who wants standardize that path expects to get "/path/tofile" while now he/she gets "//path/tofile". The current code treats with such paths as its are UNC paths by default. I believe that is wrong.

Sergei Golovin <svg>
Wed 12 Jan 2011 09:28:03 AM UTC, comment #5:

Please could you clarify what you mean by 'doesn't work' and 'is incorrect'?

You don't actually say what you think is wrong or why you think it is wrong.
Perhaps you could provide some testcases (of the form of the regression tests at http://svn.gna.org/viewcvs/gnustep/tests/testsuite/trunk/base/NSString/tests02.m) to show any problem, along with an explanation of why/how it differs from the documented behavior.

Richard Frith-Macdonald <CaS>
Project Member
Wed 12 Jan 2011 06:11:31 AM UTC, comment #4:

> "//path/file"


read as "//path/file/" (slash at the end)

Sergei Golovin <svg>
Wed 12 Jan 2011 05:58:09 AM UTC, comment #3:

It still doesn't work for pathes like "//path/file" (like an UNC resource). The function rootOf() returns the length of such a string under Linux (that is the whole string is recognised as the root. It is incorrect).

Sergei Golovin <svg>
Tue 11 Jan 2011 01:52:15 PM UTC, comment #2:

Thanks to Robert Slover for pointing out that we ought to convert multiple separators into single ones when the path is not a UNC one...

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11

I modified stringByStandardizingpPath: to check for and handle that case.

My apologies for misunderstanding the original problem.

Richard Frith-Macdonald <CaS>
Project Member
Tue 11 Jan 2011 08:11:06 AM UTC, comment #1:

The reported behavior is correct/expected (and is the documented behavior) ... path handling methods are supposed to permit both unix and windows paths by default, but there exists a mechanism to switch to non-portable path handling for people who wish to write deliberately non-portable software (eg something which will never be used on mswindows).

See the NSString documentation for more detail.:

http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSString.html

Richard Frith-Macdonald <CaS>
Project Member
Tue 11 Jan 2011 07:35:25 AM UTC, original submission:

If the path string contains extra slashes at the start (e.g. ///path/to/file) then [NSString stringByStandardizingPath] returns one extra slash in the result.

The attached test case makes following output:

2011-01-11 10:18:27.004 nsstring[25192] /path//to/file/ -> /path/to/file
2011-01-11 10:18:27.005 nsstring[25192] //path//to/file/ -> //path/to/file
2011-01-11 10:18:27.005 nsstring[25192] ///path//to/file/ -> //path/to/file
2011-01-11 10:18:27.005 nsstring[25192] ////path//to/file/ -> //path/to/file
2011-01-11 10:18:27.005 nsstring[25192] /path//to/file -> /path/to/file
2011-01-11 10:18:27.005 nsstring[25192] //path//to/file -> //path/to/file
2011-01-11 10:18:27.005 nsstring[25192] ///path//to/file -> //path/to/file
2011-01-11 10:18:27.005 nsstring[25192] ////path//to/file -> //path/to/file

, which is wrong.

The attached patch fixes the problem for me. The function rootOf() is changed because it executes the windows specific code even on my Ubuntu which leads to the wrong results for the pathes like an UNC resource (but not supposed to be the resource path), e.g. "//path/to/file/".

Sergei Golovin <svg>

 

Attached Files
file #22387:  testcase.tar.bz2 added by svg (620B - application/x-bzip - The test case and the patch)
file #22388:  gs_base_NSString_stringByStandardizingPath.patch added by svg (868B - text/x-patch - The test case and the patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by svg (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 11 Jan 2011 01:52:15 PM UTCCaSStatusInvalid=>Fixed
    Tue 11 Jan 2011 08:11:06 AM UTCCaSStatusNone=>Invalid
      Open/ClosedOpen=>Closed
    Tue 11 Jan 2011 07:35:25 AM UTCsvgAttached File-=>Added testcase.tar.bz2, #22387
      Attached File-=>Added gs_base_NSString_stringByStandardizingPath.patch, #22388

    Back to the top


    Powered by Savane 3.1-cleanup1