Re: 2002-06-20 changes in dir.c

[Pavel Tsekov <ptsekov gmx net>]

> > I found a partial discussion in June that this would cause some kind
> > of speedup. However I couldn't find the whole thread in the archives
> > and the information there is not enough so I have to ask - how does
> > this change cause a VFS speedup ? It seems the speedup will occur
> > at some point after do_load_dir () is called i.e. when printing every
> > single file entry. Then why do we have to skip the ".." in
> > handle_dirent ? Skipping ".." in handle_direntry causes an invalid
> file_entry
> > structure to be inserted later by add_dotdot_to_list () i.e. mtime,
> > atime, permission, etc are not valid. If add_dotdot_to_list () puts
> > some special information in the file_entry structure for the ".." is
> > it posible just to set this piece of information along with the
> > information returned by mc_readdir() for the parent directory ?
> 
> Not sure if I understand you, but the whole idea is not read the parent 

If you run a snapshot of MC and change the 'Listing mode' to 'Full file
list' you will most likely see that the '..' entry will contain an invalid entry
in the 'MTime'  column. Does this make the problem more obvious ? I suppose
you're aware of that fact anyway, but it's not cool to have invalid data for
the parent directory entry IMO.

> directory.  Don't assume that it's cashed.  If I go straight to 
> server:/home/user from the hotlist, server:/home is not cached, and it can
> 
> be a huge directory.

Ok I can imagine that, but isn't it better to speed up (somhow) the remote
file system 'stat' instead of just dropping specific entries from processing ?
I haven't looked at the details of how the remote stat works for any of the
supported filesystems but I intend to do so and if I come up with something
I'll put it for discussion on the list .

Thanks! :)

Pavel Tsekov

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net