Do not keep the directory handle open

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/3825
Reporter	birdie (aros@….com)
Mentions	egmont (@egmontkob), howaboutsynergy@….me

When you enter any directory using MC, the device which directory belongs to, becomes "busy" and you cannot unmount it any longer.

Please fix it.

[mc-butler]

Changed by andrew_b (@aborodin) on May 25, 2017 at 5:25 UTC (comment 1)

• Milestone changed from 4.8.20 to Future Releases

Apparently not a bug.

[mc-butler]

Changed by egmont (@egmontkob) on May 25, 2017 at 7:04 UTC (comment 2)

• Cc set to egmont

mc along with its subshell change their working directory, just as e.g. your shell does when you cd there.

I agree with andrew_b, there's no bug here, this is the desired behavior. Switch away from that directory in order to unmount the device.

[mc-butler]

Changed by birdie (aros@….com) on May 25, 2017 at 7:50 UTC (comment 3)

We may argue whether this is a bug or not, but clearly it's not an intended behaviour as it complicates the lives of MC users.

Also, until the user actually ran some command in MC, I don't understand why MC needs to spawn a shell. Please explain why the shell is needed.

[mc-butler]

Changed by egmont (@egmontkob) on May 25, 2017 at 10:09 UTC (comment 3.4)

Replying to birdie:

We may argue whether this is a bug or not, but clearly it's not an intended behaviour as it complicates the lives of MC users.

mc is not special here, I believe pretty much any other application (e.g. other terminal based or graphical file managers) would cause you this problem.

I know the frustration it causes, but the frustration would remain even if we changed mc's behavior. You'd still have to potentially find lots of other apps (including the shell from which you started mc) and terminate them.

This situation cries for a generic OS-wide solution, which could either be a standalone app showing all the apps that hold a file descriptor to a given mount point and offering to kill them, or to be able to force the unmount of a device and send input/output errors to apps that still hold a reference.

I don't think it's feasible for mc to work around a drawback of the generic Unix design.

Also, until the user actually ran some command in MC, I don't understand why MC needs to spawn a shell. Please explain why the shell is needed.

The shell is not needed, you can launch mc -u that goes without the subshell. The current unmount problem remains with mc itself, though. Plus, you'll get limited usability. Those limitations that you'll see (e.g. lack of the usual prompt, to begin with) are the exact reasons a subshell is nice to have.

[mc-butler]

Changed by howaboutsynergy on May 6, 2019 at 9:31 UTC (comment 5)

• Cc changed from egmont to egmont, howaboutsynergy@….me

imho, this should be closed

[mc-butler]

Changed by birdie (aros@….com) on May 6, 2019 at 9:54 UTC (comment 6)

Windows Explorer, FAR File Manager, Total Commander, etc. all allow to unmount (yes, there's such a thing in Windows) a device when these applications have a directory open on it and I don't understand why MC should follow any broken UNIX conventions.

Speaking of a general solution, there could be one, e.g. https://bugzilla.kernel.org/show_bug.cgi?id=14505 but it's super complicated and I don't expect the Linux kernel to have this call implemented until Linux is rewritten from scratch.

[mc-butler]

Changed by howaboutsynergy on May 6, 2019 at 20:42 UTC (comment 7)

Could maybe

umount --lazy --recursive

be of any use?

       -l, --lazy
              Lazy unmount.  Detach the filesystem  from  the  file  hierarchy
              now,  and  clean up all references to this filesystem as soon as
              it is not busy anymore.

              A system reboot would be expected in near future if you're going
              to  use  this  option for network filesystem or local filesystem
              with submounts.  The recommended use-case for umount  -l  is  to
              prevent  hangs  on  shutdown due to an unreachable network share
              where a normal umount will hang due to a downed server or a net‐
              work partition. Remounts of the share will not be possible.

       -R, --recursive
              Recursively  unmount  each  specified  directory.  Recursion for
              each directory will stop if any unmount operation in  the  chain
              fails  for  any reason.  The relationship between mountpoints is
              determined by /proc/self/mountinfo entries.  The filesystem must
              be  specified  by mountpoint path; a recursive unmount by device
              name (or UUID) is unsupported.

[mc-butler]

Changed by howaboutsynergy on May 6, 2019 at 20:59 UTC (comment 8)

Well, I was able to umount --lazy a mount point(of a mounted card reader's SDCard) [which without --lazy was busy (even with mc --nosubshell)] and so lsblk didn't list it anymore, thus I was even able to eject it.
Afterwards, mc was showing Cannot change directory even when trying to go to .. , but simply using command cd was enough to get out of the now umounted subdir structure that I was in. (there's also Tab to the other panel and Meta-i to dupe it in the opposite panel)