Ticket #3825 (new defect)
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:2 Changed 8 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 8 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 8 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 6 years ago by howaboutsynergy
- Cc howaboutsynergy@… added
imho, this should be closed
comment:6 Changed 6 years 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 years 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 years 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.
Apparently not a bug.