Re: extfs: make the open_archive stat() optional

[Pavel Roskin <proski gnu org>]

Hello!

> > The right solution would be to avoid mc_stat() in the "archiveless"
> > filesystems.
>
> Here is the patch. It checks the archive existence only when the extfs.ini
> says that it should need it. But it sends the archive filename to the
> script regardless to the 'archive need' setting.
>
> BTW: I'm getting tired with the discussion and repeated patches I'm
> sending.... You know what to do and don't want to do it yourself. It is a
> matter of few line changes, but I really don't know what do you want.

I think it's a misunderstanding.  When I said about "the right solution" I
didn't mean that you should do it so that I could accept your patch.  I
just meant that it's something I'd like to see in the code some day.

In fact, I asked you to leave VFS code alone and implement the filesystem
in the script.

> I would better give it up and make my own mc that trying to get these
> little change to the CVS code. My mtools are working here. You can always
> add the needed checks to the patch I sent. It would be educative instead
> of frustrating experience then.

Sorry for that.  I don't remember asking you to add any checks.  In fact,
I wanted you not to remove some checks.

> Please, let me know if you are interested in the mtools extfs that makes
> use of the archive name as a drive letter.

No.  It's a wrong approach.  Drive letter is a part of the path inside the
"archive".

I tried to make an archiveless mtools script, and the biggest problem is
that the "list" command is issued only once, so if we want to support more
than one disk, recursive mdir should be run on all disks from a: to z:
(or all drives listed in /etc/mtools.conf).  Not only is is slow, but
"mdir b:" can actually hang for a long time in some configurations.  Maybe
people with misconfigured drive B: in CMOS should fix it, but I expect
some bugreports if we decide to scan all disks.

I can also imagine that some users may have c: pointed to an existing
Windows disk with a lot of software on it, and it would take a lot of time
to scan that disk.  Those users will be annoyed if they only want to
access the floppy.

An alternative would be to use a two-stage approach, similar to the one
used in rpms/trpm.  The "mtools" filesystem would list disks as "a:", and
then we would have an association for "?:" to the "a" filesystem.  That
would be very close to your approach, except that mc_stat() on /#mtools/a:
would succeed.

I think both approaches could be explored.  I'll let you know if I make
any progress.

-- 
Regards,
Pavel Roskin