Bug 362288 - Kate treats remote filesystems as locally mounted
Summary: Kate treats remote filesystems as locally mounted
Status: RESOLVED WORKSFORME
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: 3.13.2
Platform: Mint (Ubuntu based) Linux
: NOR grave
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2016-04-26 09:42 UTC by adr.fantini
Modified: 2018-09-27 16:17 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description adr.fantini 2016-04-26 09:42:46 UTC
When a file in a local file system is modified, Kate creates backup files. This is fine.
When this happens for a remote filesystem (e.g. sftp), it does not do so, because it would hugely slow down the saving if the network is slow or if the ping is bad.

However, for many applications, remote filesystems can be mounted locally (e.g. with SSHFS, NFS or similar). Kate will NOT recognize this, and treat the files as locally mounted. This sometimes causes endless, minutes long delays (not even being able to move the cursor) even when just entering a single character and is short makes Kate completely unusable.

This is not a rare occurrence, but an extremely annoying bug which means Kate cannot be used in business environments with networked user data.

Reproducible: Always

Steps to Reproduce:
1. Mount a remote filesystem locally, usa a slow network
2. Edit a file with Kate
3. Experience the slowness

Actual Results:  
Kate freezes while trying to write the backup file

Expected Results:  
Kate should recognize, by looking at mount, fstab or mtab, that the current filesystem is remote, and act accordingly
Comment 1 nerd65536+kde 2016-04-30 00:48:02 UTC
Do you mean the backup file (foo.txt~) that is created when saving, or the swap file (.foo.txt.kate-swp) that is repeatedly updated while editing?
I suspect you're referring to the swap file.
In either case, the behavior is configurable in Settings -> Editor Component -> Open/Save -> Advanced

I suggest either disabling the swap file, or specifying a alternative directory on a local filesystem.
Comment 2 adr.fantini 2016-04-30 07:02:32 UTC
(In reply to nerd65536+kde from comment #1)
> Do you mean the backup file (foo.txt~) that is created when saving, or the
> swap file (.foo.txt.kate-swp) that is repeatedly updated while editing?
> I suspect you're referring to the swap file.
> In either case, the behavior is configurable in Settings -> Editor Component
> -> Open/Save -> Advanced
> 
> I suggest either disabling the swap file, or specifying a alternative
> directory on a local filesystem.

Both of them, but of course the swap file is the most annoying. I did check for the option, but I missed it. It probably is not present in the old Kate version we have at work?
Anyhow, I still think that the fact that Kate considers locally mounted remote shares as local storage is Kate's problem, the user should not need to understand and edit the options (which may not be obvious to everyone).
Comment 3 Kåre Särs 2016-05-01 12:43:07 UTC
I disagree with the thought of Kate having to take care of knowing if the path is a mounted remote file system or not. That would be a feature that would be platform- or even distro-dependent and would break really easily!

A solution could be to time the saving of the swap-file and pop up a dialog if the time exceeds some limit.
Comment 4 adr.fantini 2016-05-01 12:48:51 UTC
(In reply to Kåre Särs from comment #3)
> I disagree with the thought of Kate having to take care of knowing if the
> path is a mounted remote file system or not. That would be a feature that
> would be platform- or even distro-dependent and would break really easily!
> 
> A solution could be to time the saving of the swap-file and pop up a dialog
> if the time exceeds some limit.

How can it be distro-dependent? Getting the FS type from a path is an info that should be readily available in any distro.
Comment 5 Kåre Särs 2016-05-01 13:05:05 UTC
On söndag 1 maj 2016 kl. 12:48:51 EEST you wrote:
> https://bugs.kde.org/show_bug.cgi?id=362288
> 
> --- Comment #4 from adr.fantini@gmail.com ---
> (In reply to Kåre Särs from comment #3)
> 
> > I disagree with the thought of Kate having to take care of knowing if the
> > path is a mounted remote file system or not. That would be a feature that
> > would be platform- or even distro-dependent and would break really easily!
> > 
> > A solution could be to time the saving of the swap-file and pop up a
> > dialog
> > if the time exceeds some limit.
> 
> How can it be distro-dependent? Getting the FS type from a path is an info
> that should be readily available in any distro.

Yes, available in every distro but _different_ on each platform and could even 
be different in different distro versions.

The slowness of some filesystems is a problem and we need a solution to it, 
but I don't think trying to figure out if the FS is remote or not is the 
correct one. 

I might have a remote FS over gigabit ethenet which might be slow or I could 
have a slow local mount point (USB/SDcard). The problem is not remote/local 
but the slowness.

/Kåre
Comment 6 adr.fantini 2016-05-01 13:23:15 UTC
(In reply to Kåre Särs from comment #5)
> On söndag 1 maj 2016 kl. 12:48:51 EEST you wrote:
> > https://bugs.kde.org/show_bug.cgi?id=362288
> > 
> > --- Comment #4 from adr.fantini@gmail.com ---
> > (In reply to Kåre Särs from comment #3)
> > 
> > > I disagree with the thought of Kate having to take care of knowing if the
> > > path is a mounted remote file system or not. That would be a feature that
> > > would be platform- or even distro-dependent and would break really easily!
> > > 
> > > A solution could be to time the saving of the swap-file and pop up a
> > > dialog
> > > if the time exceeds some limit.
> > 
> > How can it be distro-dependent? Getting the FS type from a path is an info
> > that should be readily available in any distro.
> 
> Yes, available in every distro but _different_ on each platform and could
> even 
> be different in different distro versions.
> 
> The slowness of some filesystems is a problem and we need a solution to it, 
> but I don't think trying to figure out if the FS is remote or not is the 
> correct one. 
> 
> I might have a remote FS over gigabit ethenet which might be slow or I could 
> have a slow local mount point (USB/SDcard). The problem is not remote/local 
> but the slowness.
> 
> /Kåre

Yes, different on different platforms, this is true. But the same in any linux distro, by just parsing the output of mount.

Anyhow, if one could detect and solve the problem at the base, that is work around the possible slowness of some filesystems / devices, regardless of the filesystem, of course this would be even better.
Comment 7 Dominik Haumann 2016-05-01 19:35:39 UTC
Possible fix, see review request https://git.reviewboard.kde.org/r/127805/
Comment 8 Massimo Burcheri 2016-06-21 13:08:17 UTC
Same issue on Kate 3.14.21 when using KDevelop: NFS is slowing down every single character typing. From the 15s sync I would have expected some delay every 15s, but not every character. This is not usable for files on remote filesystems.
With some other NFS I did not notice that, maybe some servers are faster. The swapping should pop up a warning on any filesystem if the response time breaks the most important feature of an editor: Typing

Disabling swapping and restarting kdevelop solved it.
However I tried swapping to some local location which lead to some other bug 364596.
Comment 9 Christoph Cullmann 2016-09-05 11:48:16 UTC
We do no sync (beside each xx seconds like configured) and I use Kate the whole day on NFS and have no issues. I see no reason why it should bomb the server with write requests.

Please try a KF5 version, perhaps there was some different behavior in the KDE 4 variant.
If that still stalls for you in KF5, reopen.

Sorry for the problems.
Comment 10 Andrew Crouthamel 2018-09-26 22:09:48 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 11 adr.fantini 2018-09-27 15:18:01 UTC
I cannot reproduce this anymore personally, but the setup I had at work changed in the meantime, so who knows.