.goutputstream file appears when saving another file

[GammaRBurst]

Actual and expected behaviour

I often open files through Caja, so when I work on them is always open in the background. Sometimes, when saving said files, another file appears, whose name starts with ".goutputstream" followed by a dash and some random letters and numbers. This behavior is at least a few years old and documented also here, for example.
They don't appear only in displayed directories, but also in directories I visited. I'm not sure they appear in directories I never visited from the moment I booted the computer.
Edit: Seems like these files don't appear if I've never visited the directory from the moment I boot the computer.
Edit 2: More likely, it seems like it's a matter of where the directory is. If the visited directory is an ancestor of the directory the file is saved in, no .goutpustream file appears. If on the other hand the visited directory is the one where the file is saved, or one of its descendants, I will find .goutpustream files after saving a file.
I've enabled viewing invisible files, otherwise they can't be seen.
These files don't actually exist, trying to open them or seeing their properties is like trying to open a deleted file. I suspect they are an "echo", for lack of a better word, of the saving process, a temporary file or something similar that should disappear as soon as the process is complete, but remains visible until I refresh the window.

Steps to reproduce the behaviour

I noticed that this happens more often with some program and almost never with others. For example Geany produces a lot of these files (I'd say one for every two saves), while I don't remember ever seeing such a thing while saving a file through Python code.

Other file managers, like the ones found in Ubuntu 7.04-14.04 and Lubuntu 19.04 (PCManFM), never show these files.

MATE general version, package version and Linux distribution

Right now I'm on Ubuntu MATE 20.04, with kernel 5.4.0-42, MATE version 1.24.0 and Caja version 1.24.0.

I hope that's all that's needed, otherwise I'll add more details as you request.

Thanks a lot for the help and for all the great work done.

[lukefromdc]

I've seen this from time to time for years, both in Debian and Ubuntu

[thesquash]

I can explain where this behavior comes from.

The GNOME community created a library called GLib. (Please don't ask me exactly what it stands for.) From string management to file management, GLib is a bridge between the operating system and a portable application. Geany is one example of an application which uses GLib, but others include Caja and... pretty much every MATE and GNOME application, actually, as well as some other totally unrelated applications like FontForge.

Now let me explain what happens exactly. The file management part of GLib is called GIO. (OK. GLib also contains some file-management parts not part of GIO. But that's besides the point.) When an application uses GIO to save a file, GIO does not save the file with its original name; it actually saves the file with a randomized name starting with '.goutputstream-'. Why? Well, suppose you have a file called 'file.txt'. You have spent 5 hours creating the initial version. You save it. Then you spend another 5 hours modifying it in an editor. Then you save it again, overwriting the original copy. What if a power failure were to occur right when the file was in the middle of being saved? The answer is, conventionally, you might wind up with your five hours of work lost, you might have a file which is mostly your new file and part your old file, or worse, you may have a totally corrupted filesystem and you can't read anything.

GIO's technique is to save the file with a random name, then once the file is fully saved, rename it to the desired name, thus in effect overwriting the original. The "issue" you are seeing in Caja is Caja noticing the file, by chance, at the exact moment it's saved. The file is renamed before Caja realizes it's been renamed, and thus the entry for the file remains in Caja for seconds after it's renamed. When you click on the "file", Caja can't find the file anymore and it goes from there.

This per se is not really an issue in any program, package or distribution. However, I do agree that Caja probably should not display files that don't exist anymore.

To developers: I suspect that the issue occurs because I-Notify (the kernel mechanism Caja uses to find out when files are created and deleted) gets overloaded with the "file creation" and "file deletion" messages, and thus the second message never arrives.

My (hypothetical) proposed workaround: After some file is created, check back a second later or something and see if the file still exists.

That's all I have to say for now.