Re: FtpFS problem

[Pavel Roskin <proski gnu org>]

Hi!

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

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.

-- 
Regards,
Pavel Roskin