Subject: Re: Problems with current Bero and VR code.

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 17 Mar 1999 11:17:13 -0500 (EST)

On Tue, 16 Mar 1999, Randall S. Winchester wrote:

> : This looks like a local 'ls' program problem.  At least the GNU 'ls' on my
> : Linux box doesn't need -L to behave correctly.  I'll ask a couple of my
> : Solaris testers to take a look at this; maybe it needs a localization for
> : Solaris when MAPPING_CHDIR is defined.
> 
> I get this on *everything* including Linux.

Oh duh!  You're right.

What we have here is a disconnect between how we'd like to see symlinks
appear on a long listing (-l option for ls) and how we'd like them to
behaved when named directly (-L option).  Both methods are aguably
correct.

What's unfortunate here is the orginal posting claims that this
disconnect, when taken together with the MAPPING_CHDIR feature, causes
problems for some clients.  That's a pretty strong argument for using -L
even though I'd really like to try to not have that option appear on the
listing itself.

It may be a few weeks/couple months before I get a chance to look into it;
maybe someone would like to consider what it would take to have the daemon
look for a symlink as the _specified_ parameter for LIST and actually pass
ls the resolved name .. maybe this is as simple as always passing the LIST
parameter through fb_realpath() ... ???

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 18 Mar 1999 00:24:08 -0500 (EST)

On Wed, 17 Mar 1999, Gregory A Lundberg wrote:

: What we have here is a disconnect between how we'd like to see symlinks
: appear on a long listing (-l option for ls) and how we'd like them to
: behaved when named directly (-L option).  Both methods are aguably
: correct.
: 
: What's unfortunate here is the orginal posting claims that this
: disconnect, when taken together with the MAPPING_CHDIR feature, causes
: problems for some clients.  That's a pretty strong argument for using -L
: even though I'd really like to try to not have that option appear on the
: listing itself.

Right I was not happy with it either.

: It may be a few weeks/couple months before I get a chance to look into it;
: maybe someone would like to consider what it would take to have the daemon
: look for a symlink as the _specified_ parameter for LIST and actually pass
: ls the resolved name .. maybe this is as simple as always passing the LIST
: parameter through fb_realpath() ... ???

Ahh, that is a good idea... How about this, which seems to do the trick;
If realname is a directory, and we are doing a LIST or NLIST, then call the
command (ls_XXX) with the realname as the argument. To the user it looks
like they are calling the original "name".

Note: Line numbers will not match...

diff -u -r1.2 ftpd.c
--- ftpd.c      1999/03/18 05:13:13     1.2
+++ ftpd.c      1999/03/18 05:18:34
@@ -3473,7 +3473,13 @@
     } else {           /* run command */
         static char line[BUFSIZ];
 
-        (void) snprintf(line, sizeof line, cmd, name), name = line;
+#ifdef MAPPING_CHDIR
+        if ((stat_ret = stat(realname, &junk)) == 0 && S_ISDIR(junk.st_mode)
+                && !retrieve_is_data)
+            (void) snprintf(line, sizeof line, cmd, realname), name = line;
+        else
+#endif
+            (void) snprintf(line, sizeof line, cmd, name), name = line;
         fin = ftpd_popen(line, "r", 1), closefunc = ftpd_pclose;
         st.st_size = -1;
 #ifdef HAVE_ST_BLKSIZE

Randall

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 18 Mar 1999 11:30:51 -0500 (EST)

> +++ ftpd.c      1999/03/18 05:18:34

Close.  It uses the output from wu_realpath() which is the real, true,
honest-to-the-gods, full pathname so it should not work for guests or
anonymous users (or I'm missing something when I coderead it).

This _is_ the idea I was thinking of, though, and I very much appreciate
the patch since it gets me in the right area of the source code.  For
various reasons, VR17 went into the can early this month so I'll put this
on the list for VR18.

--

---

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 18 Mar 1999 11:35:57 -0500 (EST)

On Thu, 18 Mar 1999, Gregory A Lundberg wrote:

: On Thu, 18 Mar 1999, Randall S. Winchester wrote:
: 
: > Ahh, that is a good idea... How about this, which seems to do the trick;
: > If realname is a directory, and we are doing a LIST or NLIST, then call the
: > command (ls_XXX) with the realname as the argument. To the user it looks
: > like they are calling the original "name".
: > 
: > Note: Line numbers will not match...
: > 
: > 
: > diff -u -r1.2 ftpd.c
: > --- ftpd.c      1999/03/18 05:13:13     1.2
: > +++ ftpd.c      1999/03/18 05:18:34
: > @@ -3473,7 +3473,13 @@
: >      } else {           /* run command */
: >          static char line[BUFSIZ];
: >  
: > -        (void) snprintf(line, sizeof line, cmd, name), name = line;
: > +#ifdef MAPPING_CHDIR
: > +        if ((stat_ret = stat(realname, &junk)) == 0 && S_ISDIR(junk.st_mode)
: > +                && !retrieve_is_data)
: > +            (void) snprintf(line, sizeof line, cmd, realname), name = line;
: > +        else
: > +#endif
: > +            (void) snprintf(line, sizeof line, cmd, name), name = line;
: >          fin = ftpd_popen(line, "r", 1), closefunc = ftpd_pclose;
: >          st.st_size = -1;
: >  #ifdef HAVE_ST_BLKSIZE
: 
: Close.  It uses the output from wu_realpath() which is the real, true,
: honest-to-the-gods, full pathname so it should not work for guests or
: anonymous users (or I'm missing something when I coderead it).

Ahh, well, maybe so... I did not test it in anonymous mode. I will look at
it later today or tonight when I get a free moment.

: This _is_ the idea I was thinking of, though, and I very much appreciate
: the patch since it gets me in the right area of the source code.  For
: various reasons, VR17 went into the can early this month so I'll put this
: on the list for VR18.

Thanks,
Randall