Atom changes open files when file simultaneously edited and saved in external applications that renames and replaces on save

[jborovicka]

Edit by @rsese

1. Open some file in Atom atom --safe file
2. Open the same file in Vim
3. Edit and save the file in Vim

Expect the file to be updated in Atom with the changes from (3), actual is that the tab in Atom now shows file~ and has the content of the file before (3).

Reproduces on Windows 10 with Atom 1.26.1.

From #17186 (comment):

Simple way to recreate with a git-for-windows bash shell:

touch banana.txt
atom banana.txt
sleep 5  # Give atom time to open the file
# Simulate an external file save
mv banana.txt banana.txt.backup
touch banana.txt

Atom will end up with "banana.txt.backup" opened up, when the expected behavior is to have the new "banana.txt" either automatically loaded or for atom to warn that the file was modified.

Prerequisites

• [X ] Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

When a file (say test.tex) is simultaneously open in Atom and Scientific Workplace 5.5 (SW), and the file is edited and saved in SW, the window in Atom changes from test.tex to test.bak, instead of refreshing the content of test.tex.

Notice that the simultaneous editing and refreshing works correctly when using SW and WinEdt simultaneously, or when using WinEdt and Atom simultaneously. But not when using SW and Atom.

Steps to Reproduce

To reproduce, make sure that the "Create backup (.bak) Files" option is switched on in SW under Tools -> User Setup -> Files (this is the default choice).

1. Create a file test.tex in an empty directory, e.g., containing
   \documentclass{article}
   \begin{document}
   Some text.
   \end{document}

2. Open the file using Atom. Left pane contains the content of the directory (only test.tex), right pane the content of the file.

3. Open the file using SW. Now the file is opened in both editors. SW created a temporary file test.aaa in the directory but we can ignore that one.

4. Edit the file in Atom and save. When moving focus back to SW, a dialog window in SW announces that the file has been overwritten and request reload. Click Yes. This is expected. The file on the hard drive is correctly modified.

5. Now edit the file in SW and save. SW correctly saves the file and creates a backup (.bak) file with the previous content. This is expected. HOWEVER, at the same time, the file test.tex opened in Atom automatically changes to test.bak (the caption in the header of the window changes), and its contents indeed correspond to the test.bak file created by SW, This is incorrect behavior.

Expected behavior: When the file test.tex is edited and saved in SW, Atom should refresh the opened file.

Actual behavior: The opened file in Atom changes from test.tex to test.bak.

Reproduces how often: Always.

Versions

Same behavior in Atom 1.24.0 and Atom 1.26.0, both clean installations, with no extra packages and including in safe mode.

Windows 10, Scientific Workplace 5.5

Atom : 1.24.0
Electron: 1.6.16
Chrome : 56.0.2924.87
Node : 7.4.0

Atom : 1.26.0
Electron: 1.7.11
Chrome : 58.0.3029.110
Node : 7.9.0

Additional Information

N/A

[jborovicka]

I originally described this behavior as part of issue #17179 but apparently this is distinct from the file locking problem, hence I file it separately.

[jborovicka]

Here is an animated GIF showing how to replicate the issue.

[sgtnoodle]

I also brought this issue up and got merged into #17179. That ticket's made some progress the last few days and and this backup file behavior is looking to be an independent issue.

This problem effects me too when using IAR workbench, but it occurs when using any text editor that uses a rename-then-replace access pattern to avoid corruption.

Simple way to recreate with a git-for-windows bash shell:

touch banana.txt
atom banana.txt
sleep 5  # Give atom time to open the file
# Simulate an external file save
mv banana.txt banana.txt.backup
touch banana.txt

Atom will end up with "banana.txt.backup" opened up, when the expected behavior is to have the new "banana.txt" either automatically loaded or for atom to warn that the file was modified.

I can see how it's beneficial for atom to automatically follow a file through a rename, say when renaming or moving a source file in a code base. I do that all the time. This incompatibility with other editors, though, affects me daily. Perhaps on a rename, atom could wait a second or so to see if the original file is recreated before going along with the rename?

[rsese]

Thanks for finding this issue @sgtnoodle 🙇 From your previous comment in #16420 (comment), I was able to reproduce the behavior with Vim on Windows 10 using Git for Windows.

[lee-dohm]

I can understand why this is frustrating for certain workflows. On the other hand, this isn't exactly a common problem. This isn't something that the Atom maintainer team is going to work on in the near- or medium-term, so I'm going to go ahead and close this issue. I've flagged it as help-wanted so that people who are interested in helping out can find it though and we would be open to a well-written pull request for this change. It would probably need to be an option though because some people (especially on macOS where this is definitely expected behavior) depend on this behavior.

Thank you very much for the detailed explanation. I know that I didn't quite understand what was being described or requested when I saw this before 🙇

[sgtnoodle]

@lee-dohm Is it possible that this problem seems rare because the majority of developers in this situation quickly give up and switch to other editors? That's certainly the case for at least 5 people in my office. There's quite a few software engineers in the world that are stuck working with proprietary windows based toolchains and the only thing that makes it bearable is a good text editor. In that sense, atom in its present state is unbearable. Not to complain about you guys prioritizing other issues first, it's perfectly understandable. I might spend a few hours this week reading through the code base to see if there's an easy fix. Can you clarify what you mean about expected behavior on macOS? Why is it definitely expected for Atom to follow files through a rename on macOS? Sorry if it's something obvious to a mac user, I mainly work on linux and windows.

[lee-dohm]

Sorry if it's something obvious to a mac user, I mainly work on linux and windows.

No need to apologize, I switched from Windows to Mac a number of years ago and this is just one of those things that is different between the two world-views 😀 The best way that I can describe it is that macOS is "document-focused" whereas Windows and Linux tend to take a "filesystem-focused" point-of-view.

When I open a document in an application on macOS, I'm intending to work on that document. If I use some other tool, such as the Finder (macOS' equivalent of Windows Explorer), to move that document somewhere else in the filesystem, the application still has that document open pointing to the new location on the filesystem. So when I then save the document, the latest changes are written in that new location.

Conversely, when I open a file in an application on Windows, I'm intending to work on that specific version of the file saved in that location. If I use some other tool, such as Windows Explorer, to move that file somewhere else in the filesystem, the application still has that file open pointing to the original location on the filesystem. So when I save the file, the latest changes are written in the original location.

These are the expected behaviors on the two platforms (I assume that Linux is similar to Windows because of its hacker-friendly history). If you use something like Notepad on Windows and TextEdit on macOS, you should be able to duplicate the described behavior exactly.

[sgtnoodle]

@lee-dohm I see. I recall a coworker a few years ago select-all'ing the files in his Finder window and dragging them to a new directory. What he hadn't noticed, though, is that he had inadvertently clicked away from his project directory to the "All My Files" view. That took him about two weeks to recover from!

When you're working on a source file on a mac, doesn't that source file still need to exist in a predictable location within a directory structure in order for it to be version controlled and integrated with a build system? Or are you talking about dragging around whole project directories? I don't need to move project directories around very often, but I could imagine other workflows where that happens frequently.

Atom's ability to follow a file through an explicit rename seems like a generally useful feature regardless of the operating system it's running on. From what I've seen in the source code, my guess is that the issue described on this ticket still occurs on a mac if you were to use an editor that does the same rename-then-recreate pattern.

I can think of two potential approaches to fixing the issue on this ticket:

Option 1: Within src/path-watcher.js, modify NSFWBackend's event handler to internally timestamp and queue events in a FIFO. Asynchronously pop events from that FIFO. Whenever a "renamed" event is popped, block until the event is older than some duration (say 100ms). After that duration, check to see if there's something at the old path. If there is, drop the "renamed" event and instead emit a "modified" event for the old path and a "created" event for the new path. Otherwise, non-"renamed" events are emitted immediately without modification.

The end result should be that events go out basically how they do now. When a file is genuinely moved, things will be notified about it just the same only with a barely perceivable delay. The existing code already specifies a "100ms" debounce passed in to NSFW, so another 100ms doesn't seem too bad. When a file is renamed and quickly re-created by another editor, the events will correctly indicate that the file was modified. In a worst case scenario of a whole directory getting moved and many files generating a "renamed" event (is that even what happens?), the additional delay will still be barely perceivable since the asynchronous emitter blocks based on each event's time spent in the FIFO instead of blocking a fixed amount of time for each event.

Option 2: Basically do the same thing as Option 1, but implement it in the NSFW package.

This seems like a less elegant approach since the NSFW package is just faithfully doing its job. This whole intention around renaming text files seems above its pay grade. Maybe it's an easier place to implement the logic though, and it could be made optional and default to turned off. There's already a "debounce" parameter whose name to me implies that it would be involved in resolving some sort of ambiguity. As far as I can tell, though, the debounce parameter just controls how often the NSFW main loop polls its various native filesystem watching APIs.

[heftyfunseeker]

It's too bad this issue was closed. I get the same behavior when saving files in Visual Studio.

[jtthewoodworker]

I agree with heftyfunseeker. I've been testing Atom and Sublime and love Atom much more, except for this problem. Because of this problem, I can't use Atom. Sublime and all other editors I've tried don't have this issue.
The issue is, for me: When I have a file open in Atom and in Visual Studio (2017), make a change in VS2017 and save it, Atom changes the name of my file in it's buffer to one with an extension of *.TMP and doesn't ask me if I want to reload the newer version from disk. Atom seems to lose the relationship with the previous filename that it was editing.
For instance, I created a new file named test.txt. Created it in Atom and opened it in VS2017. Now when I edit the file in VS2017 and save it, the file name in Atom changes to test.txt~RF6a73f2e6.TMP.

I can NOT use Atom acting like this and I see no way to change this action. Sad. I like everything else, but this is a killer for me.