lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Improper ~/ expansion in file://


From: Klaus Weide
Subject: Re: lynx-dev Improper ~/ expansion in file://
Date: Fri, 20 Nov 1998 11:41:46 -0600 (CST)

On Thu, 19 Nov 1998, Ryan Hung wrote:

> On Thu, 19 Nov 1998, Klaus Weide wrote:
> 
> > I see the same in 2.8.1rel.2. 
> 
> Yeah, I guess I should have said >=2.8.1.
> 
> > There are actually at least two problems.  Only in combination do
> > they prevent changing file permissions from working:
> > 
> >  1) the additional slash in the URL
> >  2) The functions in LYLocal.c do the wrong thing with the strings
> >     they get.  In this case permit_location() gets passed
> >     "//home/username", which it passed to HTfullURL_toFile, which
> >     is a macro to a call of HTnameOfFile_WWW() [in HTFile.c].
> >     HTfullURL_toFile() is inappropriate here.  It treats the
> >     string as a relative URL (so that "home" is seen as the host
> >     part of an URL) which it isn't. It also tries to URL-unescape
> >     the string which is also inappropriate: See what happens
> >     for a file named "%backup%~".
> > 
> >     Earlier versions of LYLocal.c didn't do all this.  For example
> >     permit_location() worked for filepaths with duplicate slashes
> >     (which are just ignored under Unix) and for filenames with "%".
> > 
> > I suggest reverting LYLocal.c back to a previous version that is
> > better behaved, or changing the new macros and functions there to
> > something appropriate.
> 
> Hmm, I'll see if that works.

On further thought, it won't work to just use an older LYLocal.c, because
older versions used the tempname() function which doesn't exist any more.
Unless you can find a version which doesn't use tempname() but doesn't
have the HTfullURL_toFile() yet.

> Any idea why adding a few lines to LYUtils.c
> under LYTrimRelFromAbsPath() doesn't seem to do the trick:
> 
> Added at Line 4569:
> 
>     while (cp[1] == '/') {
>         if (cp[2] == '/') {
>         /*
>          *  Skip over first "/" of a "//". - rhung
>          */
>         cp += 1;
>         } else {
>         /*  Finished. - rhung
>          *
>          */
>         break;
>         }
>     }
>
> After all, the "if (url_type == FILE_URL_TYPE)" section in LYGetFile.c
> seems to call LYTrimRelFromAbsPath().

It may or may not work, but that seems to be just fiddling around with
the symptoms.  And I hope you would then carefully examine all places
where LYTrimRelFromAbsPath() gets called, and check whether your change
is always appropriate (and for all operating systems!).  The problem
should be solved where it is generated, which is where the /~ is replaced
by something else.

The code in getfile that expands "/~" looked like this in a previous
incarnation:

                            StrAllocCopy(temp, doc->address);
#ifdef DOSPATH
                            StrAllocCat(temp, "/");
                            StrAllocCat(temp, HTDOS_wwwName((char 
*)Home_Dir()));
#else
#ifdef VMS
                            StrAllocCat(temp,
                                        HTVMS_wwwName((char *)Home_Dir()));
#else
                            StrAllocCat(temp, Home_Dir());
#endif /* VMS */
#endif /* DOSPATH */
                            if ((cp2 = strchr(cp1, '/')) != NULL) {
                                LYTrimRelFromAbsPath(cp2);
                                StrAllocCat(temp, cp2);
                            }
                            StrAllocCopy(doc->address, temp);
                            FREE(temp);
 
It has been replaced by:

                            StrAllocCopy(temp, doc->address);
                            LYAddHtmlSep(&temp);
                            StrAllocCat(temp, wwwName(Home_Dir()));
                            if ((cp2 = strchr(cp1, '/')) != NULL) {
                                LYTrimRelFromAbsPath(cp2);
                                StrAllocCat(temp, cp2);
                            }
                            StrAllocCopy(doc->address, temp);
                            FREE(temp);

which apparently doesn't do the same thing.

> > Note that permit_location() should always get a filename or file
> > path as its srcpath argument, not a URL.  The code
> > 
> >          if (strncmp(srcpath, "file://localhost", 16) == 0)
> >             srcpath += 16;
> >  
> > which appears in previous versions may have been misleading because
> > if makes one think otherwise.  But AFAIK that test would normally
> 
> Yeah, that's what %p in lynx.cfg should be doing, giving the path.  It's
> just that it gives the wrong path, "/username" rather than
> "/home/username".

Only if you had something like

  DIRED_MENU:FILE::Modify Permissions::LYNXDIRED://PERMIT_SRCfile://localhost%p

in your lynx.cfg could such a thing be generated.  I can't think of any
reason to do that. :)

Even in that case, the part after "file://localhost" would _still_ be
a file path and not an URL path.  Which makes a difference when you
think of '%'-escaping, and possibly for other reasons.  So there _still_
is no reason to use HTfullURL_toFile().

   Klaus

reply via email to

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