Bug 362288

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.

(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).

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.

(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.

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

(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.

Possible fix, see review request https://git.reviewboard.kde.org/r/127805/

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.

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.

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!

I cannot reproduce this anymore personally, but the setup I had at work changed in the meantime, so who knows.