Rob Heittman wrote:
Learn something new every day! Makes sense. Just resolve the
relativisms then?
I'm not entirely sure we should
Anyway, I am afraid that on a file-system you can't do one without the other
suppose I have
/home/mpo/path/symlink => /var/whatever/target
then what should be the resolution of:
file:/home/mpo/path/symlink/../stuff
should it get me:
file:/home/mpo/path/stuff
or:
file:/var/whatever/stuff (linux and the java canonicalPath take this)
Continuing in this view to 'resources'
supposing there is something like
http://server/path/context-y/alias-for-x giving me the same as
http://(other?)server/canonical-x
what would be the least surprising:
that
http://server/path/content-y/alias-for-x/../some-resource
reproduces
http://server/path/content-y/some-x-rersource
or rather
http://(other?)server/canonical-x/../some-resource
Dunno but maybe there is some spec or guideline on relative notations in
URI's and how they should be 'cleaned out' / 'resolved'.
Haven't took the time to delve into your use case yet, is there anything
braking by these relativisms, or is it just a bit of a nuisance?
regards,
-marc=
----- Original Message -----
From: "Marc Portier" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, September 19, 2007 7:52:26 AM (GMT-0500) America/New_York
Subject: Re: Bug: DirectoryResource is broken if used with relative paths
Rob Heittman wrote:
>
> With trunk rev 2170 Joel's problem still manifests.
>
> I confirmed issue 352 solved, but this is something different.
> LocalReference.getFileReference() does not make the ./ go away. I think
> it should:
>
> LocalReference.java:86
> < return createFileReference(file.getAbsolutePath());
> > return createFileReference(file.getCanonicalPath());
>
> Unless there is a useful reason to create a LocalReference that still
> contains ./ and ../ etc -- I can't think of one.
>
unless I'm missing something here:
the compelling reason was symbolic links
http://restlet.tigris.org/issues/show_bug.cgi?id=337
point being: the difference between absolute/canonical is about more
then only resolving ./ and ../ in paths (which is quite logic since
purely textual resolving the ./ and ../ might yield to quite different
results then what you expect when symbolic links are in use)
regards,
-marc=
> ----- Original Message -----
> From: "Jerome Louvel" <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Tuesday, September 18, 2007 5:13:35 PM (GMT-0500) America/New_York
> Subject: RE: Bug: DirectoryResource is broken if used with relative paths
>
>
> Hi all,
>
> This bug lied in the File connector in is now fixed in SVN. Thanks for
> testing it.
>
> Best regards,
> Jerome
>
> > -----Message d'origine-----
> > De : Rob Heittman [mailto:[EMAIL PROTECTED]
> > Envoyé : mardi 18 septembre 2007 15:48
> > À : [email protected]
> > Objet : Re: Bug: DirectoryResource is broken if used with
> > relative paths
> >
> >
> > Thanks for trying it anyway, Joel, I wasn't at an actual
> > computer yesterday.
> >
> > Something like this works around the issue for me:
> >
> > String path = null;
> > try{
> > path=new File("./").getCanonicalPath();
> > } catch (IOException handleMePlease) {}
> > LocalReference lr = LocalReference.createFileReference(path);
> > Directory directory = new Directory(getContext(),lr);
> >
> > You need to get the "." and ".." resolved away, which
> > getCanonicalPath()
> > does.
> >
> > I think LocalReference should do this for you when you pass a
> > File as in
> > your original example -- thoughts, Jerome, Thierry?
> >
> > Also, I think LocalReference.getTargetRef() oughta return a
> > LocalReference
> > (you'd have to cast it, but this should work).
> >
> > - Rob
> >
> >
> > ----- Original Message -----
> > From: "Joel Nelson" <[EMAIL PROTECTED]>
> > To: [email protected]
> > Sent: Monday, September 17, 2007 8:00:26 PM (GMT-0500)
> > America/New_York
> > Subject: Re: Bug: DirectoryResource is broken if used with
> > relative paths
> >
> > On Mon, 17 Sep 2007 11:26:08 -0400, Rob Heittman wrote:
> >
> > > 1)
> > > // Create a directory able to expose a hierarchy of files
> > > Directory directory = new Directory(getContext(),
> > > LocalReference.createFileReference(new File("./").getPath()));
> > >
> >
> > This one is equally broken
> >
> > > 2)
> > > // Create a directory able to expose a hierarchy of files
> > > Directory directory = new Directory(getContext(),
> > > LocalReference.createFileReference(new File("./")).getTargetRef());
> >
> > This one doesn't compile, "The constructor Directory(Context,
> > Reference)
> > is undefined"
> >
> >
