Re: Nasty MC bugs still not fixed

[Pavel Roskin <proski gnu org>]

Hello!

> > >     1) sometimes mc fails to change to _existing_ directories, and complains

You didn't specify how mc complains and how to reproduce the problem.

> > >     2) sometimes it just reflect that it has changed to the dir, by updating the
> > >   panels, but dont actually do the dirchange, and when one tries to type in
> > >   some command it tells what "cant exec command - shell is active"
> > >   or smth like that. I suppose chdir call stalls of smth like that.

If I understanfd you correctly, it's an intrinsic defect of the subshell
implementation in MC.  MC uses the same subshell for all commands.  MC
instructs the shell to report when it's ready.  If at least one symbol has
been sent to the shell since then, the shell is considered "Busy".
Feeding a new command to the shell is unsafe because the user could
started some command.

Suppose that MC doesn't keep track of the shell status.  I press Ctrl-O,
enter "rm -rf " and press Ctrl-O.  Now I change to a directory named
"subdir".  MC sends "subdir\n" to the shell.  Then the shell would execute
"rm -f cd subdir", which is not what you want.

I don't think that MC can reliably interpret all keystrokes intended for
the shell, which would be required to save, clean and restore the subshell
command buffer.

> > >     3) while copying large amount of files (>4GB), the size progress
> > >   bar everytimes == 0%

I could not reproduce it on RedHat Linux 7.1 (i386) with the CVS version
of MC.

Note that --enable-largefile is default in CVS, but not in 4.5.55.  You
shouldn't expect MC compiled without large (64-bit) file support to work
correctly with large files.

> > How To Ask Questions The Smart Way, by Eric Raymond and Rick Moen:
> > http://www.tuxedo.org/~esr/faqs/smart-questions.html
> >
> > How to Report Bugs Effectively, by Simon Tatham:
> > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
>   I`m sorry, but these bugs are there already ~20 versions, or likely more...
>  (and pretty much likely more)

Those documents are not only about specifying the version of the piece of
of software that exhibits the problem.  Perhaps you should _really_ read
those documents.

> > >     4) it _is_ the time to use madvise(VM_SEQ_READ) on large files.
> > >   that i suppose _will_ drmatically increase large file transfer speed.
> > >   actually i`d like to see tunable the value from which the file io will
> > >   be madvised to be streaming...
> > >
> > >   the algo is next: 1. mmap file 2. madvise the memregion 3. do the io
> > >
> > >   hmm... thats all i can remeber for the moment...
>     5) Search is b0rken:
>         if you are grepping in the directory for "foo" you can fail, even
>   if files containing "foo" exists. Even more if foo is expected to be
>   surrounded by spaces like that " foo ", and you will reflect this,
>   entries will be found, while still failing on "foo".
>     This bug i hate most, since i have to use grep to be sure.

MC skips binary files with the recent versions of GNU grep.  This will be
fixed in the next version.  The patch that replaces egrep invocations with
calls to the regexp library will be applied soon.

> > Not enough details:
> >
> > 1) Which OS'es are affected?
>  Linux
> > 2) Which operations are affected?
>  Usual operation. All is described above.

Is this interface documented?  What other programs are using it?  I don't
want MC to be the only program to fail if the interface changes.  I looked
into grep-2.4.2 and it doesn't use VM_SEQ_READ.  Maybe there is a
downside?

Also I found this in /usr/include/linux/mm.h (Linux 2.4.3-12smp from
RedHat 7.1):

#define VM_SEQ_READ     0x00008000      /* App will access data
sequentially */

MC doesn't always read data sequentially.

Can you make a patch and provide some measurements demonstrating speed
increase?

-- 
Regards,
Pavel Roskin