Github: Git - File is corrupted when discard changes

Created on 16 Jan 2018  Â·  24Comments  Â·  Source: atom/github

From @nagman on January 15, 2018 7:17 AM CST - copied from atom/atom#16566

Prerequisites

Description

When you discard changes of a line or a group of lines in the Unstaged Changes view, it corrupts the file and you can't edit it anymore.
The only solution I've found so far is to restart the computer.

Steps to Reproduce

  1. Open a file
  2. Do some changes
  3. Save them
  4. Go in the Unstaged Changes panel and click on the file
  5. Select the line you changed
  6. Right clic -> discard selection

Expected behavior:
I actually don't know what "discard selection" should do (I'm not an expert in Git), but I clicked on it by mistake while I wanted to click on "Stage selection".

Actual behavior:
The file becomes corrupted.
There's a yellow warning message saying: "Unable to save file: Permission denied".
The file also sometimes disappear from the left sidebar (not in safemoden though, so I suppose this is related to the settings where you can hide the ignored files).

You can't save it, you can't edit it, you can't delete it, and sometimes you can't open it.
I managed to open it with vim in console, but even with superadministrator rights (Windows) or sudo mode (bash for Windows) I couldn't delete it.

I had to restart the computer and THEN I could find my file back marked as deleted in the Unstaged Changes panel. Then I discard it and the file comes back in my sidebar.

Reproduces how often:
Each time I do the above steps (tried 3-4 times).

Versions

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

apm 1.18.12
npm 3.10.10
node 6.9.5 x64
atom 1.23.3
python
git 2.14.1.windows.1
visual studio

needs-reproduction

Most helpful comment

I too have this problem.
I'm using v1.26.1 on windows 10 and my project folder is not under user.

All 24 comments

Here's an update about this bug:
I've reinstalled Atom from scratch but this new bug still happens.
Now, sometimes when I pull changes, it deletes the file I'm editing and corrupts it.
The only way to get this file back is to restart the computer.
Otherwise, I can't open it, view it, delete it, rename it...

The file also sometimes disappear from the left sidebar (not in safemoden though, so I suppose this is related to the settings where you can hide the ignored files).

Just to clarify, if you run in safe mode does that only affect the file showing in the tree view on the left or is all the behavior you describe not reproducible in safe mode?

Also, what version of Windows are you running?

The only difference between safe mode and normal mode is that the gitignored files show on the left.
But the main bug (corrupted files when pulling or discarding... or maybe anything to do with git in atom) is also happening in safe mode.

I'll tell you tomorrow what version of Windows I'm using (not on my computer now).
But after the last bug I had, there was a big Windows update. Maybe it is fixed?

Also, just for you to know, I'm using Bash for Ubuntu for running node servers.
But I do all the git stuff with the Windows prompt.
That would be strange that Bash corrupts my files because this bug never happened before 10 days ago.

I'm having the exact same issue and it also happens in Safe Mode here. This affects both my local machine and my laptop and also all repositories on both machines. Also both devices have identical versions of Atom, Node, Git and Windows.

It's also happening all the time, so i can fully reproduce again it if you need additional data.

Video:
https://streamable.com/575jb

Versions:

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

apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.26.0-beta0
python
git 2.16.1.windows.1
visual studio

Windows 10 x64 Version 1709 (Build 16299.309)

Error in Console:

Uncaught (in promise) GitError: git -c color.ui=false -c color.status=false -c color.showBranch=false -c color.diff=false -c color.branch=false apply - in D:\Dokumente\Rainmeter\Skins\Monstercat-Visualizer exited with code 128
stdout: 
stderr: error: unable to write file 'visualizer.ini' mode 100644: Permission denied

    at new GitError (C:\Users\Marco\AppData\Local\atom\app-1.26.0-beta0\resources\app\node_modules\github\lib\git-shell-out-strategy.js:104:24)
    at C:\Users\Marco\AppData\Local\atom\app-1.26.0-beta0\resources\app\node_modules\github\lib\git-shell-out-strategy.js:372:33
    at Generator.next (<anonymous>)
    at step (C:\Users\Marco\AppData\Local\atom\app-1.26.0-beta0\resources\app\node_modules\github\lib\git-shell-out-strategy.js:92:197)
    at C:\Users\Marco\AppData\Local\atom\app-1.26.0-beta0\resources\app\node_modules\github\lib\git-shell-out-strategy.js:92:367
    at <anonymous>

Thanks for the video!
I was about to do it but you did it before me.

I'm having same problem
Any workaround?

@GeDrax Not a known one for now, just keep off discarding changes for now.

I'm also seeing this issue. Same versions of Atom and Windows as @MarcoPixel above (although I've also seen this with previous versions of Atom). When I revert changes to a file, I lose all access to the file. Windows Explorer reports that the file still exists (but, according to the file's size, the change was not actually reverted), but I do not have read access to the file, nor can I delete it. When I close Atom, the file disappears. This is also happening in safe mode.

Thanks for the video @MarcoPixel - I tried again on Windows 10 with Atom 1.25 but was unable to reproduce.

It looks like the first report is against 1.23.3, can anyone confirm if this used to work ok in previous versions of Atom?

Also, can anyone think of any other programs that might be running on your system that could possibly be related (e.g. file backup, anti-virus, etc.)? @MarcoPixel if you copy the project to your home directory, can you still reproduce?

@rsese Okay, so i've uninstalled Atom, reinstalled with version 1.23.0 and cloned my repo so we have a blank state. (Video: https://streamable.com/gbfd6)

It worked without issues and i thought okay that it might be a issue with the version, so back to 1.26.0-beta0 and it also worked there without issues (Video: https://streamable.com/otme9) so i thought it might be a issue with my atom installation.

So then i thought it might be fixed so i've tried it out on another repo i had cloned and lo and behold it doesn't work (at least not completly). On the second repo it wouldn't discard the changes, but it would allow the file still to be writable so i can remove the changes manually (what wasn't possible before until i restarted Atom), but there is a new error thrown only into the console.

Video: https://streamable.com/gl665

Error Message:

Uncaught (in promise) GitError: git -c color.ui=false -c color.status=false -c color.showBranch=false -c color.diff=false -c color.branch=false apply - in C:\Users\Marco\siege-ui exited with code 1
stdout: 
stderr: error: patch failed: src/index.ejs:8
error: src/index.ejs: patch does not apply

    at new GitError (C:\Users\Marco\AppData\Local\atom\app-1.26.0-beta0\resources\app\node_modules\github\lib\git-shell-out-strategy.js:104:24)
    at C:\Users\Marco\AppData\Local\atom\app-1.26.0-beta0\resources\app\node_modules\github\lib\git-shell-out-strategy.js:372:33
    at Generator.next (<anonymous>)
    at step (C:\Users\Marco\AppData\Local\atom\app-1.26.0-beta0\resources\app\node_modules\github\lib\git-shell-out-strategy.js:92:197)
    at C:\Users\Marco\AppData\Local\atom\app-1.26.0-beta0\resources\app\node_modules\github\lib\git-shell-out-strategy.js:92:367
    at <anonymous>

Unable to find item at path src\index.ejs with staging status unstaged at <embedded>:278207

Thanks for the update @MarcoPixel - that new error you're getting has already been reported here if you want to subscribe:

https://github.com/atom/github/issues/837

Based on your description it sounds like you installed an older version and things worked but then went back to 1.26.0-beta0 and after initially working, it stopped working again? Can you install an older version (the latest 1.23 again or the latest 1.24 version) and see if the problem pops up during continued use?

In https://github.com/atom/atom/issues/17013 it was mentioned that this only happens when the project folder is located in the user folder. Moving the project folder to another location resolved the issue.

atom/atom#17013 did indeed fix the "permission denied"-error, but only regarding rebasing! I just tried and i too am able to reproduce the error by discarding changes everytime.

So, the easiest way to delete a file right now is to make some changes to it and then discard the changes. It saves me the trouble from confirming that i really want to delete it.

@Ben3eeE This is incorrect as this also happened on my D: drive (D:/reponame).

@rsese I'm gonna report back and tell you if the problem returns on my local machines :)

I too have this problem.
I'm using v1.26.1 on windows 10 and my project folder is not under user.

Actually, it seems it's a matter of rights shared amongst the 2 OS (Windows and Ubuntu for Windows).
I don't have anymore bugs now that I cut my current processes (like Angular, React or even a simple Gulp task) before pulling.
Because the git used by Atom is the Windows' Git, and it interacts with the same files as my Node processes which run on Linux. So both are trying to modify files with a different file system and it sometimes (or always) corrupts files.
When stopping the processes, it can resolve those conflicts, but not always.

Is there any solution for this problem? Only solution to this i know is to delete local repository and clone it as new one... with loss of all work i have done before preparing commit.

Thanks a lot

this issue bother me a lot recently. a possible solution for this:
Open atom in Administrator mode possibly fix it. At least to me.

Since there have been a couple of releases since this report and a similar issue was fixed in that time, can folks that are still hitting this issue confirm a few things?

  • You're on Windows
  • You can reproduce as described in the steps to reproduce from the issue body
  • You can reproduce on Atom 1.28.1 or Atom 1.29.0-beta1

Then if you can reproduce, can you think of anything running on your system that could possibly be related (e.g. anti-virus, working on files on a network drive, file backup program running, etc.)?

So far we've been unable to reproduce this issue unfortunately.

i have updated atom and problem was fixed. Thanks a lot

I used to have this issue. Now I cannot reproduce it with Atom 1.28.0 or 1.28.1 on Windows.

Thanks @kamil-babula @yha - @nagman since you opened the issue originally, can you confirm if you can reproduce with Atom 1.28.1 or Atom 1.29.0-beta1?

hi. Like I said previously i am not able to reproduce the issue again - with 1.28.1 it works fine.

Was this page helpful?
0 / 5 - 0 ratings