Discarded changes doesn't refresh file

GPlay97 commented 6 years ago

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: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
- Followed all applicable steps in the debugging guide: http://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

Edit by @rsese - steps to repro from below

sudo sysctl fs.inotify.max_user_watches=400 - setting it to a super low value to generate the error (was set to 65536 on my Ubuntu vm)
start Atom in atom/atom atom --safe .
Open devtools console ctrl-shift-i and see the same error as @stratacast ("NSFW was unable to start watching that directory")

Now if you open a file in Atom and then edit that file in some other program (e.g. vim), any changes outside of Atom won't reload the file in Atom and you can save over the changes.

Description

If I make some changes within a file, which is linked with Git, it marks the changed lines. If I then discard my changes, the color of the filename changes from modified to grey, which is fine. But the modified lines won't get unselected and I still see those line if I've still open the file. If I close and open the file again, the lines are gone.

Steps to Reproduce

Make some changes within a file within a Git Repository.
Save.
Discard the changes while the file with the changes is still open.

The current visible file should be refreshed. The discarded changes should also be thrown away with the file you are currently looking at. Furthermore the modified lines color should disappear.

Actual behavior: The file doesn't show the new, discarded changes. It still has the "old version".

Reproduces how often: Every time.

Versions

Atom : 1.22.0 Electron: 1.6.15 Chrome : 56.0.2924.87 Node : 7.4.0

OS: Debian 9 (stretch) Linux version 4.9.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28)

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue. screenshot_2017-11-21_09-53-28

rsese commented 6 years ago

Thanks for the report - I'm unable to reproduce with Atom 1.22.0 on Ubuntu 16.04.

Just to confirm, can you reproduce with any project (e.g. a simple 1 file test project) or just a particular project?

GPlay97 commented 6 years ago

I can reproduce this kind of error behavior with every Git Project (not linked with GitHub as remote), even with a one file test project. I just need to create a new local repository with git init, create a file, commit, change something and discard the changes to get this error. It then only refreshes, if I close and re-open the file again.

GPlay97 commented 6 years ago

To give you a little update - I also have the problem of not refreshing, when I right-click a file and click on "Delete file" - the file removes from the current view, but it remains on the tree view. Only closing and re-opening the folder in which the file was, refreshes the list.

So I think I have a general problem with refreshing here in Atom (and Debian?).

rsese commented 6 years ago

So I think I have a general problem with refreshing here in Atom (and Debian?).

Since I can't reproduce with macOS 10.12.6 or Ubuntu 16.04, I don't think it's a general issue with Atom but maybe could be something specific with Debian? If anyone else is running Debian and can reproduce, that would be helpful to know.

Also just to confirm, you installed with the official .deb from https://atom.io?

GPlay97 commented 6 years ago

Also just to confirm, you installed with the official .deb from https://atom.io?

Yes :+1:

rsese commented 6 years ago

Oh also, did you see the same behavior with previous versions of Atom or only starting with 1.22?

GPlay97 commented 6 years ago

Previously I had version 1.19 I think - with no problems.

Yesterday I tried it also on my other machine with the same debian. It has version 1.21 installed with no problem. I will update to 1.22 there later and report, if I get the same error there too

GPlay97 commented 6 years ago

@rsese Incredible - since today I don't have any problems anymore. I haven't made any changes. It just works now fine. No matter what I do. The problem with the discarded changes came after the upgrade of 1.22, and now, it just disappeared - doing nothing

GPlay97 commented 6 years ago

@rsese Nevermind - now I have a problem again with the refresh of the tree view and the file. I've commited my changes and pushed. Now, the file is still yellow and the changes are still marked within the file. After about 30 seconds suddenly it disappeared

rsese commented 6 years ago

To clarify, on both of your debian machines running 1.22.1 you see this behavior?

GPlay97 commented 6 years ago

@rsese That's now superstrange. I had version 1.22 installed. And had the problems sometimes. Now I've updated to v.1.22.1 and I can't reproduce any of this behavior again. It's now working fine :+1: But I can't say, what the problem was. In the changelog of atom, I couldn't find anything interesting, which could explain this "bug".

GPlay97 commented 6 years ago

@rsese Or not.... Suddenly I have the issue again - with 1.22.1. So it seems to be some kind of a (debian) based problem, but it's not persistent, it happens only sometimes?! /Edit: This time I commited my changes - they still got marked after commiting and pushing as changed.. After about half a minute, it disappeared again..

GPlay97 commented 6 years ago

To give you a new update @rsese - the problem still persists here on my debian machine (only here, on Ubuntu it's working fine): After I'm commiting my changes, they are still marked yellow or green. Even within the tree view the file is marked as changed. But if I tab out and change the window, and then return to Atom, Atom got focus and refreshes everything right. Maybe that's some hint for you, since re-focusing solves the problem for me.

stratacast commented 6 years ago

I have this same issue on Fedora 27 right now. Except it doesn't even have to be git-related, it can just be any file I have open in Atom. The problem happened on 1.22, now on 1.23.3, and in 1.24-beta3

stratacast commented 6 years ago

Update: This problem does not affect me with 1.19.7. I had to run sudo sysctl fs.inotify.max_user_watches=32768fs.inotify.max_user_watches = 32768 to get rid of the warning, and all my files refresh as they're supposed to in Atom. So this is some regression somewhere with file refreshing

GPlay97 commented 6 years ago

@stratacast Thank you so much! Entering the command sudo sysctl fs.inotify.max_user_watches=32768 solved the problem! Now, everything works fine, I can discard and commit! Yeah!

rsese commented 6 years ago

Update: This problem does not affect me with 1.19.7. I had to run sudo sysctl fs.inotify.max_user_watches=32768fs.inotify.max_user_watches = 32768 to get rid of the warning, and all my files refresh as they're supposed to in Atom. So this is some regression somewhere with file refreshing

Wow thanks for sharing your findings @stratacast, I'm glad that fixed things for you and @GPlay97 :+1:

Curious if there were there any errors in console during your testing?

I'll try to reproduce in my VM by setting sysctl fs.inotify.max_user_watches to a lower value.

stratacast commented 6 years ago

I don't see anything in the console DURING my tests, but I do see this as soon as I open the console

That is an error present in the current beta build. However, in 1.19.7, I only see this:

rsese commented 6 years ago

Thanks @stratacast - I can reproduce now:

sudo sysctl fs.inotify.max_user_watches=400 - setting it to a super low value to generate the error (was set to 65536 on my Ubuntu vm)
start Atom in atom/atom atom --safe .
Open devtools console ctrl-shift-i and see the same error above

Now if you open a file in Atom and then edit that file in some other program (e.g. vim), any changes outside of Atom won't reload the file in Atom and you can save over the changes.

stratacast commented 6 years ago

I'm glad you were able to reproduce this! I increased the value on my system to the one I noted above, and the issue is also fixed for me in 1.24.0-beta3.

EDIT:

Quick DDG search to make this permanent:

Edit the /etc/sysctl.d/99-sysctl.conf file and add fs.inotify.max_user_watches = 32768

Restart your system or run sysctl --system

smashwilson commented 5 years ago

Ah, okay, this looks like how I'd expect things to break once you've exhausted your inotify watch descriptor quota on Linux.

If you're feeling adventurous, try changing the "File System Watcher" core setting to "Experimental filesystem watching library" rather than "native operating system APIs." You will still see some degradation (increased latency, moderate increase in CPU usage) once watch descriptors are all taken, but the experimental library should fall back to a throttled polling implementation and keep us limping along 😉

Now if you open a file in Atom and then edit that file in some other program (e.g. vim), any changes outside of Atom won't reload the file in Atom and you can save over the changes.

To give you a little update - I also have the problem of not refreshing, when I right-click a file and click on "Delete file" - the file removes from the current view, but it remains on the tree view. Only closing and re-opening the folder in which the file was, refreshes the list.

☝️ I do expect issues like these two to persist even with the filesystem watcher implementation toggled. The tree view, git-diff package, and TextBuffer are not yet using the core watchPath API to create filesystem watchers, so they will continue to fail ungracefully once descriptors are gone.

I'm going to close this because it should be addressed by the @atom/watcher transition work. If you experience crashes, lockups, or other stack traces in your console with the experimental watcher, please file them as new issues on the atom/watcher repository so we can track them separately 🙇

Other issues and pull requests related to the watcher transition that may be of interest to you:

atom/tree-view#1232 is the PR to transition tree-view to using watchPath. (Note that this is a pretty big undertaking, so it's likely to stall out a few times before we can land it.)
17899 is the PR to default Atom to the experimental filesystem watcher.

lock[bot] commented 5 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

atom / atom