id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	branch_state	votes
4636	Fails to read directory if resized while external editor was running	egmont	andrew_b	"Have two different directories in the two panels. Make sure the ""other"" panel has lots of files.

Edit a file in ""this"" panel using an external editor by pressing F4. (Note that executing the command ""my-editor filename.txt"" doesn't trigger the bug, it has to be F4, and it has to be an external editor. Interestingly, F3 with an external viewer doesn't trigger the bug either.)

While running this external editor, resize the terminal.

Quit the external editor. `mc`'s default look of two panels is back.

The ""other"" panel contains lots of incorrect entries. Many of the files appear with invalid type ('?' before the filename), dated Jan 1 1970, and in red (error) color. As if stat() failed on them.

----

In fact, `strace` shows that `mc` concatenates ""this"" panel's directory and the ""other"" panel's filename, and tries to stat() that, which indeed almost always fails.

Here's what happens according to `strace`, after quitting the external editor:

First, both panel's directory is listed and all the files are stat()ed correctly.

Then, a little bit later, the other directory is listed again (`getdents64()`), and the first dozen or so files are `newfstatat()`'ed there as expected, but then this gets interrupted for a while.

The next ~200 lines are about totally different things. stat()'ing /etc/localtime many times, reading /proc/self/mountinfo multiple times, and even doing some UI update stuff, apparently actually painting mc's entire display. (No sign in strace of this being related to a SIGWINCH or other signal arriving.)

Then, after these ~200 lines of strace output, `stat()`'ing the directory entries continues, but this time under the wrong directory. (Could perhaps some global variable, containing the directory path, changed during those ~200 lines??)

Note that when `mc` first starts up and everything is okay, `stat()`'ing the directory entries is then also interrupted at the very same position (after the first dozen-ish entries) for a `pselect()` call, trying to read from one of its pipe file descriptors with a 0 timeout. But then `pselect()` doesn't report any data available. When the bug occurs, it begins with that same `pselect()` which then returns that data is available, and the next step successfully reads a single `\0` byte from that pipe. This is the beginning of those ~200 lines of things that somehow break the directory.

I can reproduce this bug with 4.8.31, 4.8.33, and current master (post `4630_resize`). Cannot reproduce on another machine with 4.8.25."	defect	closed	major	4.8.34	mc-core	4.8.33	fixed					merged	committed-master