Bug 421716 - Kate does not open when not connected to a remote sshfs folder after reboot
Summary: Kate does not open when not connected to a remote sshfs folder after reboot
Status: RESOLVED DUPLICATE of bug 415501
Alias: None
Product: kate
Classification: Applications
Component: application (show other bugs)
Version: unspecified
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-18 06:32 UTC by Donno
Modified: 2020-11-06 05:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Donno 2020-05-18 06:32:55 UTC
SUMMARY


STEPS TO REPRODUCE
1.Have a remote folder created by sshfs 
2.Open file using kate  
3.Reboot pc and kate does not open any file until you reconnect to sshfs 

OBSERVED RESULT
Kate hangs in the background

EXPECTED RESULT
Kate opens with error to say remote folder does not exist

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Debian 10.4
(available in About System)
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.54.0
Qt Version: 5.11.3

ADDITIONAL INFORMATION
Comment 1 Justin Zobel 2020-10-30 05:13:52 UTC
Donno I've just tried to recreate this issue however I am not sure I am doing the same as you.

- I mounted a folder over ssh with sshfs ip:/folder/ temp
- Opened a file from that temp folder in Kate
- Closed Kate and unmounted the temp folder
- Opened kate but no error

Do you have some sort of session load automatically at start of kate?
Comment 2 Donno 2020-11-03 05:54:48 UTC
1.Have a remote folder created by sshfs 
2.Open file using kate
3.Reboot pc and kate does not open any file until you reconnect to sshfs 

I think kate should have a timeout and throw error and not just loop to try and reconnect.(In reply to Justin Zobel from comment #1)
> Donno I've just tried to recreate this issue however I am not sure I am
> doing the same as you.
> 
> - I mounted a folder over ssh with sshfs ip:/folder/ temp
> - Opened a file from that temp folder in Kate
> - Closed Kate and unmounted the temp folder
> - Opened kate but no error
> 
> Do you have some sort of session load automatically at start of kate?

after you open file don't unmount just restart PC. After restart kate tries to reconnect to file with no timeout or error, it only hangs !
Comment 3 Justin Zobel 2020-11-03 06:44:26 UTC
OK so I've tested this with a reboot after opening the remote (sshfs) file in kate.

Kate reopens when my session starts and I have a blank file but with the filename open.

I'm setting this to confirmed as it's not stopping kate from opening but it is opening a blank file with the filename set which is not helpful.
Comment 4 Scott Lerman 2020-11-05 16:51:50 UTC
I'm not sure if it's the same cause, but I get the same behavior with Kate 20.08.1 on Windows. I have Kate set to reopen the last session on startup. If I had any files on a network share open, and I haven't reconnected the network drive, Kate fails to start.

I've also seen Kate immediately crash if I lose the connection to the network share, but I can't reproduce the crash by simply unmapping the network share.

Could this issue possibly be related to https://bugs.kde.org/show_bug.cgi?id=415501 ?
Comment 5 Donno 2020-11-05 19:41:39 UTC
(In reply to Scott Lerman from comment #4)
> I'm not sure if it's the same cause, but I get the same behavior with Kate
> 20.08.1 on Windows. I have Kate set to reopen the last session on startup.
> If I had any files on a network share open, and I haven't reconnected the
> network drive, Kate fails to start.
> 
> I've also seen Kate immediately crash if I lose the connection to the
> network share, but I can't reproduce the crash by simply unmapping the
> network share.
> 
> Could this issue possibly be related to
> https://bugs.kde.org/show_bug.cgi?id=415501 ?

yes that is the same thing i am doing in linux.
Comment 6 Justin Zobel 2020-11-06 05:33:40 UTC
*** This bug has been marked as a duplicate of bug 415501 ***