Ticket #3825 (new defect)

Opened 2 years ago

Last modified 6 months ago

Do not keep the directory handle open

Reported by: birdie Owned by:
Priority: major Milestone: Future Releases
Component: mc-core Version: master
Keywords: Cc: egmont, howaboutsynergy@…
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

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.

Change History

comment:1 Changed 2 years ago by andrew_b

  • Milestone changed from 4.8.20 to Future Releases

Apparently not a bug.

comment:2 Changed 2 years ago by egmont

  • Cc egmont added

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.

comment:3 follow-up: ↓ 4 Changed 2 years ago by 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.

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.

comment:4 in reply to: ↑ 3 Changed 2 years ago by egmont

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.

comment:5 Changed 7 months ago by howaboutsynergy

  • Cc howaboutsynergy@… added

imho, this should be closed

comment:6 Changed 7 months ago by birdie

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.

comment:7 Changed 6 months ago by howaboutsynergy

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.

comment:8 Changed 6 months ago by howaboutsynergy

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)

Last edited 6 months ago by howaboutsynergy (previous) (diff)
Note: See TracTickets for help on using tickets.