Re: FtpFS problem

[Pavel Roskin <proski gnu org>]

Hello, Pavel!

> > This appears to be a bug in ftpfs.
>
> It may be "feature".

No, it's a bug.

> Okay, haven't look at code, but assume you are in /foo/bar/baz. Now,
> you stat(".."). To find size of /foo/bar (that's what .. is, right?)
> you list /foo. Logical, eh?

The explanation is logical, but the implementation is not.  What is the
size of ".." anyway, especially on ftpfs?  Why should I care about size of
the directories if the protocol only allows me to download files?  Is
there any justification for wasting time and bandwidth to get useless
informations?

Actually, "ls -al" gives me the size of "..".  This is from
ftp.rutgers.edu:

ftp> ls -al
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 16
drwxr-xr-x   7 199          512 Oct  3 19:06 .
drwxr-xr-x   7 199          512 Oct  3 19:06 ..
-r--------   1 0              0 Oct  3 19:06 .forward
-r--------   1 0              0 Oct  3 19:06 .rhosts
d--x--x--x   2 199          512 Oct  3 19:11 bin
drwxr-xr-x   2 199          512 Oct  3 19:03 dev
drwxr-xr-x   2 199          512 Oct  3 19:23 etc
lrwxrwxrwx   1 199            7 Oct  3 18:59 lib -> usr/lib
drwxr-xr-x  19 0            512 Oct  4 16:54 pub
drwxr-xr-x   3 199          512 Oct  3 18:59 usr
226 Transfer complete.

If "ls -al" doesn't work then it can be (755, now, 0 bytes).

Now let me show you how it looks in gdb.  This is my .gdbinit:

file mc
set args -abu /#ftp:ftp.rutgers.edu/pub/apache/dyn/CVS
b ftpfs.c:dir_load
r

first breakpoint:
Breakpoint 1, dir_load (me=0x80dc700, dir=0x8100e38,
    remote_path=0x8100836 "pub/apache/dyn/CVS") at ftpfs.c:1172
1172        vfs_s_super *super = dir->super;

second breakpoint:
#0  dir_load (me=0x80dc700, dir=0x81144d8, remote_path=0x81144be "pub/apache")
    at ftpfs.c:1172
#1  0x080bf1db in vfs_s_find_entry_linear (me=0x80dc700, root=0x8100948,
    path=0x81144be "pub/apache", follow=-1, flags=4) at direntry.c:314
#2  0x080bf2af in vfs_s_find_inode (me=0x80dc700, root=0x8100948,
    path=0x81144be "pub/apache", follow=-1, flags=4) at direntry.c:339
#3  0x080bf0ad in vfs_s_find_entry_linear (me=0x80dc700, root=0x8100948,
    path=0x81144be "pub/apache", follow=-1, flags=0) at direntry.c:291
#4  0x080bf2af in vfs_s_find_inode (me=0x80dc700, root=0x8100948,
    path=0x81144be "pub/apache", follow=-1, flags=0) at direntry.c:339
#5  0x080bfb0b in vfs_s_inode_from_path (me=0x80dc700, name=0x81144a8 "/",
    flags=0) at direntry.c:579
#6  0x080bfdb9 in vfs_s_internal_stat (me=0x80dc700, path=0x81144a8 "/",
    buf=0xbffff620, flag=0) at direntry.c:698
#7  0x080bfe36 in vfs_s_lstat (me=0x80dc700, path=0x81144a8 "/", buf=0xbffff620)
    at direntry.c:713
#8  0x080b19e5 in mc_lstat (path=0x81144a8 "/", buf=0xbffff620) at vfs.c:607
#9  0x0805a7f6 in handle_dirent (list=0x8101160, filter=0x0, dp=0x80eb560,
    buf1=0xbffff620, next_free=0, link_to_dir=0xbffff690,
    stalled_link=0xbffff68c) at dir.c:426
#10 0x0805ab63 in do_load_dir (list=0x8101160, sort=0x8059890 <sort_name>,
    reverse=0, case_sensitive=1, filter=0x0) at dir.c:517
#11 0x0808032d in panel_new (panel_name=0x80ca475 "New Left Panel")
    at screen.c:998
#12 0x0807192c in set_display_type (num=0, type=0) at layout.c:928
#13 0x08074936 in create_panels () at main.c:1405
#14 0x080752e5 in setup_mc () at main.c:1766
#15 0x08075cfb in do_nc () at main.c:2098
#16 0x080768c6 in main (argc=3, argv=0xbffffc24) at main.c:2794
#17 0x400de2ae in __libc_start_main (main=0x8076620 <main>, argc=3,
    ubp_av=0xbffffc24, init=0x804b29c <_init>, fini=0x80c6790 <_fini>,
    rtld_fini=0x4000cf28 <_dl_fini>, stack_end=0xbffffc1c)
    at ../sysdeps/generic/libc-start.c:129

Actually, mc_lstat is called on "..", but it becomes "/" inside
mc_lstat().  Later it becomes "pub/apache", perhaps as a result of a call
to vfs_s_get_path_mangle() from vfs_s_inode_from_path().

> This might not be too easy to fix...

I agree.  Since the VFS code is commented insufficiently, it's very hard
to find where things go wrong.

By the way, I'm using gcc from 3.0.x branch on CVS and gdb from the 5.1
branch.  They are quite stable, but if something looks weird, that may be
the reason.

-- 
Regards,
Pavel Roskin