Re: FtpFS problem


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

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

Actually, "ls -al" gives me the size of "..".  This is from

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 /
b ftpfs.c:dir_load

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.
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

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