Re: Path-related asserts

Hi Daniel,

> I think we've all but beaten this to death, but one more 
> thing about case sensitivity and OS dependency.  Using a 
> single directory seperator per OS is okay, because that 
> directory seperator truely is part of the OS.  Consider CDFS: 
>  When accessing a CD on Windows, it's "D:\foo\bar" 
> whereas on linux it would be "/mnt/cd/foo/bar".  The 
> directory seperator truely is a function of the host environment.

Interesting. I didn't realize that.
 
> Case is something different though.  The various rules on 
> case in ISO 9660, RockRidge, and Joliet escape me right now 
> and I'm not sitting in front of a linux box to test, but as 
> you mentioned, linux/bash's behaviour can change based on the 
> case-sensitivity of the FS.  The directory seperator always 
> remains the same.  Just $0.02 more.
 
Hmmm... So given a path, without any knowledge of a particular
file system for which it is intended, we can't tell whether it's
case sensitive or not. In practice, we probably always know the 
file system for which it is intended, but the devil is in
the details.

Charlie
> 
> Charlie Poole wrote:
> > Hi Daniel, 
> >
> >   
> >> As you realized later, case sensitivity is not OS dependant, 
> >> but rather FS dependent.  I would hesitate to add something 
> >> to NUnit that ASSumes Windows is always case insensitive and 
> >> everything else is not, but it's your party.
> >>     
> >
> > Yes, it is an issue. And yet .NET already makes that assumption
> > by having a single value for the directory and path separators.
> > It's a bit of a puzzlement.
> >
> > My current implementation uses that single directory separator
> > value and also assumes case sensitivity when running on Windows.
> > I'm not too sure how bad that is as a default, but it's sure
> > not perfect.
> >
> > More thought needed here, I guess.
> >
> >   
> >> I'm not quite sure I understand your statement above about 
> >> canonicalizing paths.  Are you implying that the following 
> >> test should not pass?
> >>
> >> Assert.AreEqual(0,
> >> string.Compare(Path.GetFullPath("c:\\temp\\foo\\.\\bar\\.."),
> >> Path.GetFullPath("C:\\TeMp\\foo"), true));
> >>
> >> That test passes for me, and that is why I encourage that 
> >> implementation.  If there is something I am missing, please 
> >> let me know.  GetFullPath() will resolve "/" to "c:\" but 
> >> that's part of the ideal behaviour to me.
> >>     
> >
> > Actually it should resolve to the letter of your current
> > directory, which may or may not be C. It would be a problem
> > if I were testing handling of linux paths, while running
> > on Windows - which is something I do.
> >
> > I realize that having apps and tests that run in both
> > environments is a bit rare, but NUnit does it for one.
> >
> > I'll have to go back and run some tests to see exactly
> > what issue led me to write my own canonicalize. It could
> > have been because of the "C:\" thing and the change of
> > "/" to "\" but my memory is that the dots and dot-dots
> > circumstances under one of the five CLRs we test with.
> >
> > I'm sure I had a reason, but if that reason is obsolete,
> > I may be able to simplify things a bit.
> >
> >   
> >>  If the framework 
> >> makes that conversion, than the path is valid to the framework.
> >>     
> >
> > Yes. My assumption was not one may be testing paths that are NOT
> > valid in the current execution environment. That may be too
> > specialized for general use, however.
> >
> >   
> >>> Assert.That( "/abracadabra", Is.SubPathOf( "/abra" ) );
> >>>   
> >>>       
> >> Good catch.  Try this one:
> >>
> >>             Assert.IsTrue(Path.GetFullPath(PathToTest).Length 
> >>     
> >>> Path.GetFullPath(PotentialBasePath).Length && 
> >>>       
> >> string.Compare(Path.GetFullPath(PathToTest).Substring(0,
> >> PotentialBasePath.Length + 1), string.Format("{0}{1}", 
> >> Path.GetFullPath(PotentialBasePath), 
> >> Path.DirectorySeparatorChar), true) == 0);
> >>
> >> I admit it's really ugly, 
> >>     
> >
> > Glad to hear it. :-)
> >
> >   
> >> but it does prevent the false 
> >> positive you mention above as well as false positives from 
> >> the two resolving to the same path.
> >>     
> >
> > Yes, it's that ugliness that caused me to encapsulate
> > the whole thing.
> >
> > Charlie
> >
> >   
> >> dmp
> >>
> >>
> >>     
> >
> >
> >
> >
> >   
> 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/