Bug 427619 - When Dolphin is launched with a path to a disk that is attached but not mounted, the disk is not automatically mounted as expected
Summary: When Dolphin is launched with a path to a disk that is attached but not mount...
Status: CONFIRMED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2020-10-13 07:25 UTC by Franz Trischberger
Modified: 2021-08-02 16:04 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
screenshot (72.44 KB, image/jpeg)
2020-10-13 07:25 UTC, Franz Trischberger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Franz Trischberger 2020-10-13 07:25:10 UTC
Created attachment 132312 [details]
screenshot

I have an external HDD permanently attached to my dads' desktop PC. When he browsed that disk before shutting down the PC Dolphin will now try to load that dir when first starting dolphin after booting. Which fails as I do not like to auto-mounted removable media. This results in an empty view and an error message: see attached screenshot.

dolphin should try harder in this situation:
First it could try to find the media this folder belongs to. If it isn't available it could as well just load the users' home directory, probably keeping the message so the user knows something went wrong.

Reason for this report:
My dad paniced because he thought his files were deleted as the view was empty.
He saw the warning box but didn't understand it was about removable media. He thought his home directory doesn't exist. He didn't want to press any button because he was afraid this could make things worse. (Not every user is a geek...)
Comment 1 Nate Graham 2020-10-13 15:22:12 UTC

*** This bug has been marked as a duplicate of bug 158934 ***
Comment 2 Franz Trischberger 2020-10-13 15:32:51 UTC
(In reply to Nate Graham from comment #1)
> 
> *** This bug has been marked as a duplicate of bug 158934 ***

I'm not sure this really is a duplicate.
158934 is about ejecting a media while dolphin is running and showing the content of that ejected device.
This is about the new and now default behaviour to restore the last session which had a removable media opened (that's not available anymore). There is likely a reboot in between (or dolphin was closed while the media was ejected), so there is no way for dolphin to track ejecting/mounting.
Comment 3 Nate Graham 2020-10-13 16:17:04 UTC
I see what you mean.

On a slightly different subject...

> external HDD permanently attached to *my dads'* desktop PC
> [...]
> *I do not* like to auto-mounted removable media

As someone who also supports his nontechnical father's computer, I can tell you that your life will b e happier in the long run if you set up his computer according to how he likes it and what's user-friendly for him, not according to your own opinions of how a system should work. :) I would recommend turning auto-mounting on for both of your sanity.

That said, I'll see if I can fix this bug.
Comment 4 Franz Trischberger 2020-10-13 16:46:11 UTC
Thx a lot, Nate.
The reason behind not automounting goes back a while. We watched lots of DVDs (nowadays just occasionally). With mounted DVDs there were issues with ejecting, sometimes forcing me to reboot to change the disc (https://bugs.kde.org/show_bug.cgi?id=261552#c48). With the external hdd I now see this problem: it turns off after a while, when I insert a card reader or a usb stick and open it I get a delay of several seconds because also the external HDD starts up when it was mounted (should be the same with optical discs), and the LoadCycleCount unneccessarily goes up.
Comment 5 Elvis Angelaccio 2020-10-13 17:56:15 UTC
The empty view is bad, for sure. Dolphin should display the home instead.
Comment 6 Nate Graham 2020-10-13 18:00:34 UTC
Yep, working on it.
Comment 7 Bug Janitor Service 2020-10-13 19:41:10 UTC
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/77
Comment 8 Franz Trischberger 2020-10-13 19:59:42 UTC
(In reply to Bug Janitor Service from comment #7)
> A possibly relevant merge request was started @
> https://invent.kde.org/system/dolphin/-/merge_requests/77

Will this also load the user's home if dolphin was started with an invalid URL on the commandline? (I can't currently test-compile.)
Comment 9 Nate Graham 2020-10-13 20:06:44 UTC
No, only for the session-restore/remember previous window state use cases. I reasoned that if you deliberately feed dolphin a possibly invalid URL on the CLI, you probably know what you're doing and can handle seeing an error message. :)
Comment 10 Franz Trischberger 2020-10-14 10:33:03 UTC
(In reply to Nate Graham from comment #9)
> No, only for the session-restore/remember previous window state use cases. I
> reasoned that if you deliberately feed dolphin a possibly invalid URL on the
> CLI, you probably know what you're doing and can handle seeing an error
> message. :)

Great, because if the user asks dolphin to open a non-existant dir he should really see the message (and he deserves so ;)).
Comment 11 Nate Graham 2020-10-14 13:43:55 UTC
Glad you agree with my reasoning. :)
Comment 12 Elvis Angelaccio 2020-10-23 17:00:45 UTC
Git commit c733b3aa9787a618a0ce5bb03b3fc731f5663b21 by Elvis Angelaccio, on behalf of Nate Graham.
Committed on 23/10/2020 at 17:00.
Pushed by elvisangelaccio into branch 'master'.

Don't session-restore invalid paths

When session restore is populating the main window, it's unconditional;
you'll get whatever was there before. This can be a problem if any of
those things are now missing. For example, maybe you were browsing files
on a removable disk, then quit Dolphin, and finally removed the disk. The
next time you launch Dolphin again, it will try to show you the
view from the now-missing removable disk.

To prevent this, we now look at all the URLs in all of the view
containers that were created after session-restore has finished doing
its thing; if any of them are invalid local URLs, we change the URL to
the home folder instead to avoid showing the user a view with an invalid
location in it.
FIXED-IN: 20.12

M  +14   -0    src/dolphinmainwindow.cpp
M  +6    -0    src/dolphinmainwindow.h
M  +4    -0    src/main.cpp

https://invent.kde.org/system/dolphin/commit/c733b3aa9787a618a0ce5bb03b3fc731f5663b21
Comment 13 Bug Janitor Service 2021-07-28 19:01:21 UTC
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/248
Comment 14 Nate Graham 2021-08-01 21:34:44 UTC
Git commit ea7d4f059d5cb81b51053e7fec6492a727a968c2 by Nate Graham.
Committed on 28/07/2021 at 18:59.
Pushed by elvisangelaccio into branch 'release/21.08'.

Revert "Don't session-restore invalid paths"

This reverts commit c733b3aa9787a618a0ce5bb03b3fc731f5663b21.

There are people who prefer the old behavior of session-restoring all
paths including the ones which are currently inaccessible. The idea is
that Dolphin is like a web browser; if a website is not currently
available, the browser tells you that instead of silently discarding the
URL and showing you the homepage. Doing this can be considered a form
of data loss.

In addition, the reason for the change was to prevent Dolphin from
showing invalid paths on launch for unmounted removable disks, but that
specific case was fixed separately by switching to ~ for any tabs/views
that were showing locations on a just-unmounted removable disk. So you
will never run into the problem if yo unmount a disk in Dolphin and then
close it.

Accordingly, let's revert the change because it causes more problems than
it resolves.
Related: bug 439864
FIXED-IN: 21.08

M  +0    -14   src/dolphinmainwindow.cpp
M  +0    -6    src/dolphinmainwindow.h
M  +0    -4    src/main.cpp

https://invent.kde.org/system/dolphin/commit/ea7d4f059d5cb81b51053e7fec6492a727a968c2
Comment 15 Elvis Angelaccio 2021-08-01 21:35:27 UTC
Re-opening since we reverted the change.
Comment 16 Nate Graham 2021-08-02 16:04:05 UTC
For this use case, I think we can do something better than the previous change, actually. If Dolphin is launched with a path that corresponds to a disk that is attached but not mounted, Dolphin can simply mount it, considering the act of launching Dolphin to be an explicit user request to mount the disk just as if you clicked on it in the sidebar.

Alternatively you can just set this one disk of yours to auto-mount. :)