Re: FtpFS problem


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

Correct.  The size of directories makes sense sometimes, e.g.
directories with large sizes may have a lot of files in it.  However,
displaying the size of ".." is quite useless, especially since "." is not
displayed at all.

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.

Maybe.  Actually, the server may use some remapping, so stat("..") is not
necessarily the same as it looks from "../.."

If I'm on FTP in the directory "unlisted/foo" and "unlisted" is hidden
from the listing, then stat("..") will fail in its current implementation.
If I go to "/" I won't see "unlisted", which is Ok.  If stat("..") is done
locally, then I would see "unlisted" and possibly be unnecessarily worried
that my secret stuff is exposed.

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.

Sounds good.  I actually have an unfinished patch that changes "struct
file_entry" so that it includes both the results of lstat() and stat() and
allows each of them to be invalid.  Special ".." entry with invalid
flags for all [l]stat data would fit in this patch just fine.

Pavel Roskin

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