Fix crash on unmount when busy with other processes - #2823
Conversation
vjr
left a comment
There was a problem hiding this comment.
Works for me in a couple of tests except when using the Code app.
Fixes (prevents) crash-on-unmount while transferring files and while editing a file in VIM but there's maybe something in the way the Code app works I can still unmount and remount while editing a file in Code but that seems to be an issue in Code not this fix.
This can be merged for sure, any further fixes if required can be left for future PRs.
|
@vjr I think Code closes the document file after every update (and keeps a copy of its content in the text buffer) so mostly does not appear to be using it. Maybe we should mark open document files as in use? |
Where does this "mark open files as in use" change need to happen? Would you mind filing an issue ticket in the proper repo? I'm not sure whether it's supposed to be (likely?) Code or (unlikely?) Files. |
|
@vjr At the moment, Code handles the situation of unmounting the source of a document while there are unsaved changes by showing a dialog:
This gives the user the chance to remount the source or save changes elsewhere. If there are no unsaved changes, the document just closes. I presume that if the unmount was requested during a lengthy save from Code (normally documents are not large enough to take a significant time to save) then a "busy" dialog would be shown (after this PR). I'll check what other editors do. |
|
@vjr I checked Gnome Text Editor (FlatPak as native install gave weird behaviour on Wayland) and this did not inhibit unmounting a USB stick containing the file being edited. The dialog when saving after that was less helpful than Code - it simply gave an error that the file did not exist. |
|
Nevertheless I'll raise an issue to see what comments arise. |

Fixes #2821
For simplicity a Granite.MessageDialog is used for now.

A problem is that if the competing process is FlatPak'd which is likely, the name of the competing process may well be that of a portal, not the original process. Not sure how to get round that.
In principle we could offer additional choices such forcing the unmount or ending the competing processes but that is left for design input.