Has the USB mount/unmount bug been fixed?

I thought I saw some ticket or update recently concerning something to do with USB and was wondering if it had anything to do with that.

I think that you meant this commit
It said in description, it is to solve this bug. As you can see, the user provided himself a patch.
Perhaps, it can have side effects on another thing but I wouldn’t count on that.

Indeed that change is about fixing a kernel crash. If your USB problems aren’t a kernel crash, it won’t affect anything for you.

What “mount/unmount bug” are you referring to?

When I plug in a USB thumb drive and then unmount it, sometimes it doesn’t completely go away. The drive icon is still there. It’s been awhile since I last did it, but I think that trying to remount the device also doesn’t work after that point. A reboot is necessary to fix things.

I believe I posted about it here a several months ago. I’ll look and see.

Posting here doesn‘t really help. Please make a ticket : )

Here’s my original post, in Feb., if it helps:

1 Like

So far as I can tell, the bug has been fixed. Or maybe there wasn’t a bug to begin with. All I know is, now (with “Eject” enabled), my 2Gb thumb drive unmounts and vanishes without incident. Coulda sworn I had tried enabling that before and it didn’t work, but it works now, so that’s the important thing.

Has anyone a need for the option “Eject when unmounting”?
Or rather, is there a need to not eject when unmounting, i.e. un-ticking that checkbox in the Tracker prefs?

Apprently it doesn’t serve to easy un-/re-mounting a USB drive by not having to un-/re-plug the device.
Personally, I only associated ejecting an optical disc with this option. Since I don’t have such a drive for many years, I never had a need for it.

Yes, it is the only way to unmount an USB disk but still be able to edit partitions in DriveSetup. If you “eject”, the device completely disappears.

Depending on your mount settings, if you have things set to automount, you may have no other way to edit a disk in DriveSetup (which is better done with all partitions unmounted).

Shouldn’t that be handled by DriveSetup then?
I mean, then you could have the disk mounted when launching DriveSetup, and when you want to edit a partition on it, DriveSetup unmounts the disk without ejecting and you can start editing.

The option in Tracker preferences seems not to be needed generally, and is a somewhat hidden tripwire, as Luposian found


1 Like

I’m not sure about that, this option should not make any difference as to wether the icons disappears or not after unmounting. The icon should disappear in either case, but if “eject when unmounting” is enabled, the USB drive will be powered off in addition to that (and disappear from /dev/disk).

OK. Then #18938 (USB Thumb drive mount/unmount issue) – Haiku may have been closed prematurely


Hmmm 


Unmounted thumbdrive - Case #1

Unmounted thumbdrive - Case #2

Move to TRASH or Delete - remaining icons

(Translation in file names.)

Unplugged THEM :

So,

solved ?..


Edit #1:

Luposian would be happy, half, as the drive icons changed automatically to drawers - after the unmount.
Half, as it was automatical, not on demand 
 :j

Edit #2 :

Just right now I made an experiment to attempt to kick off from the other side - it worked.
You can eliminate the remaining “sticky” drive icons, if you restart Tracker - using Process Contoller to to force it. by killing Tracker.
At least I could do so.

@KitsunePrefecture I‘ve send you a warning about these kinds of posts. Please check your forum pms.

This post seems pretty reasonable to me. It would be easier if the screenshots were in a language I can understand, but at least it is very clear about the two scenarios.

Anyway, these remaining icons when a disk is unmounted should not exist, no matter if the checkbox is checked or not. So, maybe the bug only appears in one of the two cases, but it is still a bug. When you unmount a disk, the icons should disappear, no exceptions to that.

1 Like

Well I added pictures only as I was asked to not write - as I write a lot - and it is confusing to members here. (sic!)

This way I added only pictures, and gave long file names in english what is written in Hungarian or what I tried to do


I think Haiku may works well, the bug should be in Tracker 
 I mean, the OS stated always :
failure happened when I attempted to delete or move to trash those icons.
Simply as there were not there anything,anymore, but Tracker still displayed remaining for me on the Desktop - somehow stucked in - not refreshing this from actual status.

I should have listed files/directories in Terminal to be confirmed what is on filesystem level.

I think it can get closer to the truth as just I forced Tracker to be restarted - Tracker itself had not put back those icons onto the Desktop 
 meanwhile other files/directories - those really exist - reappeared on the Desktop.

Hi,

this post length is already much better. I had not seen that you replied to my message, which is why I asked about it here.

Regards

01__Plugged_in_and mounted__edited

~> cd Desktop/
~/Desktop> ls -ltra
total 1444672
lrwxrwxrwx 1 user root         44 dec.   17  2022  BeBook -> /boot/system/documentation/BeBook/index.html
lrwxrwxrwx 1 user root         10 dec.   17  2022  Home -> /boot/home
lrwxrwxrwx 1 user root         26 dec.   17  2022 'Quick Tour' -> /boot/system/bin/quicktour
lrwxrwxrwx 1 user root         26 dec.   17  2022 'User Guide' -> /boot/system/bin/userguide
-rw-r--r-- 1 user root          0 nov.    4  2023  TEXT.txt
-rw-r--r-- 1 user root     726064 åpr.    9 16:27 'MagNet - NetBank v3 Levelezés.mhtml'
-rw------- 1 user root      38677 ĂĄpr.    9 16:30  MagNet__NetBank__ÉpĂ­tsĂŒnk_közössĂ©getmhtml
-rw-r--r-- 1 user root     727018 ĂĄpr.    9 16:33  MagNet__NetBank__Telefonos_ĂŒgyfĂ©lszolgĂĄlat_vĂĄltozĂĄs__2024.mhtml
-rw-r--r-- 1 user root         18 åpr.   13 20:46 'Kellékes .txt'
-rw-r--r-- 1 user root      62167 jĂșn.    1 16:09  Web-4607-debug-01-06-2024-14-09-13.report
-rw-r--r-- 1 user root       2642 jĂșn.    9 11:24  pavancsok__Haiku.txt
-rw-r--r-- 1 user root       3807 jĂșn.   15 00:58  ThinkCentre_MTM_8187_LTG.txt
-rw-r--r-- 1 user root      63007 jĂșn.   24 23:35  Web-37568-debug-24-06-2024-21-35-03.report
-rw------- 1 user root 1477246976 jĂșn.   29 17:27  haiku-r1beta4-x86_64-anyboot.iso
-rw-r--r-- 1 user root         31 jĂșn.   30 00:05 'NĂ©vtelen kivĂĄgĂĄs'
-rw-r--r-- 1 user root      64233 jĂșn.   30 22:21  Qmmp-2989-debug-30-06-2024-20-21-26.report
-rw-r--r-- 1 user root       4034 jĂșl.   10 23:53  4HQ.txt
drwxr-xr-x 1 user root       4096 jĂșl.   15 04:32  ..
-rw-r--r-- 1 user root         35 jĂșl.   15 04:34  any_DL.txt
-rw-r--r-- 1 user root     314624 jĂșl.   17 11:13 '01__Plugged_in_and mounted.png'
-rw-r--r-- 1 user root      17595 jĂșl.   17 11:25 '01__Plugged_in_and mounted__edited.png'
drwxr-xr-x 1 user root       2048 jĂșl.   17 11:25  .
~/Desktop> ls -ltra /
total 8
drwxr-xr-x 1 user root 2048 ĂĄpr.    6 21:09 HaiQ64_Inst
drwxr-xr-x 1 user root 2048 jĂșl.   10 22:54 boot
drwxr-xr-x 1 user root    0 jĂșl.   17 10:19 dev
drwxr-xr-x 1 user root    0 jĂșl.   17 11:11 ..
drwxr-xr-x 1 user root    0 jĂșl.   17 11:11 .
lrwxrwxrwx 1 user root   12 jĂșl.   17  2024 system -> /boot/system
lrwxrwxrwx 1 user root   16 jĂșl.   17  2024 bin -> /boot/system/bin
lrwxrwxrwx 1 user root   25 jĂșl.   17  2024 etc -> /boot/system/settings/etc
lrwxrwxrwx 1 user root   22 jĂșl.   17  2024 tmp -> /boot/system/cache/tmp
lrwxrwxrwx 1 user root   16 jĂșl.   17  2024 var -> /boot/system/var
lrwxrwxrwx 1 user root   26 jĂșl.   17  2024 packages -> /boot/system/package-links
lrwxrwxrwx 1 user root    5 jĂșl.   17  2024 HaiQ64_R1B5 -> /boot
~/Desktop> 

I see now, why I cannot delete or move those icons - such icons just conveniency for us, users - delivered by Tracker only (I assume with C++ code).
.
I knew that already
the drives mounted under “/” really, but I thought it appears with relinking onto desktop.

So this way noone can remove those icons from Desktop with file operations.

Edit : now I could unmount /eject without any issue, twice. As secondary I used the drive : copied to files as first time I just mounted for the picture above, and found nothing on filesystem level in Dekstop dir.
Next time I wanted an experiment when I use it too.

Strange. Just as for Luposian, I had not done anything, but now no more issue.

Ok so, now I tried it on R1B4 hrev56578+96 ,
and issues above happened on Haiku nightly hrev57820.

From my experience it is easier to trigger the issue if you have pending operations on the drive, sitting in the file cache or block cache.

For example, copy a lot of files to a USB disk, then immediately after Tracker says the copy has completed, try to eject it, you’re pretty sure to run into the problem.

But, if you use the sync command in Terminal before unmounting, it will be a lot more likely to unmount cleanly.