Re: FtpFS problem

[Pavel Machek <pavel ucw cz>]

Hi!

> > > 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?

What is size of ".." anyway, even on normal filesystem? Mostly
useless.

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

Yep. But at the time stat("..") is done, ftpfs probably does not know
that it had stat info of ".." handy.

Okay, this should be fixed.

> 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.

Sorry for bad commenting...

> 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.

Okay, my proposal for fixing: for sake of consistency, "invent"
.. entries. Always. Show something like ".."  <PARENT_DIR> and don't
bother showing its size.

That may well be right solution. If size of ".." is useless, make it
invisible, even on normal filesystems.
                                                                Pavel
-- 
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.