Often when I do a checkout of a different branch, or a reset, I will get 'permission denied' errors from windows for one to a dozen files - but the particular files vary from run to run. Here's the output from a test I just did, with GIT_TRACE=1. The trace only added the one line before the error message:
$ git checkout master
trace: built-in: git 'checkout' 'master'
error: git checkout-index: unable to create file dotnet/src/myfile.cs (Permission denied)
D dotnet/src/myfile.cs
Switched to branch "master"
I'm pretty sure this is some race with a virus scanner or other indexing service on my machine. If the race persisted, I could use sysinternals to see what process has the file handle open. However, it happens very quickly, and I'm not aware of a tool that will show me this conflict. Surprisingly, I haven't found anyone describing similar behavior.
How do I make these errors stop, or diagnose the problem further?
I'm specifically looking to end the file access race by identifying whatever process is doing the simultaneous access. So suggestions for a tool that shows which process has a file locked when an edit is denied would be very helpful. I'm aware of 'unlocker' and similar tools which will show me what process holds a file locked for a period of time. This doesn't work for this issue, because the process keeps the file locked for a very short period. So the tool needs to collect the appropriate data without my intervention, as I'm too slow.
It might be the Windows Search Indexer, which tries do index files as they are created. I ran into this issue with svn checkout and had to exclude that directory from indexing before I could successfully checkout a full project.
See my post https://connect.microsoft.com/VisualStudio/feedback/details/676699/cannot-open-linker-output-for-writing-or-cannot-close-file
Not git related!
Sysinternals' process monitor reveals that Windows explorer interferes with newly created files, perhaps due to some plugin or what, but it happens.
Disabling UAC Virtualization seems to have fixed the problem.
See http://code.google.com/p/msysgit/issues/detail?id=320
You can begin with a:
GIT_TRACE=1
But it may not display much more than your original message regarding this file.
The usual cause is some opened editor which wants to reload the files when changed, and that can conflict with git's file manipulations.
That means: the usual strategy is to repeat your git command after having close as many other applications as you can.
I haven't found anyone describing similar behavior
See this thread for instance, ot this one, both on Cygwin.
What version of Git are you using (Git on Cygwin, or MSysGit, in a Cygwin session or a Dos session?)
You could try Filemon from sys internals
Related
My primary development environment is within Windows but for Git, I try to mainly use the command line for doing most things and occasionally use TortoiseGit for others (such as viewing viewing logs or rebasing). Usually when switching branches, there are no problems when it's removing and restoring files. But certain programs lock these files (e.g., editing CSV files in Excel) which causes minor issues when switching branches.
If switching from the command prompt and a file is locked, it'll simply notify you that it was unable to unlink the file and ask you if you want to retry. This will give me a chance to close the program that has the lock and let it try again.
switching from command prompt
However, if I were to switch branches through TortoiseGit, it will have the error but will act as if the response was N and finish up leaving the files in their current state. It gets a little annoying as I have to go back and manually revert the files. I'd rather have it wait and ask me to try again, like it usually does with other actions.
switching from TortoiseGit
Is there any way I can force TortoiseGit to halt and ask me to retry unlinking the file when switching branches? Or is this just not a feature of TortoiseGit?
Up to TortoiseGit 2.2.3 the yes/no question wrapper (GIT_ASK_YESNO) was not implemented. Starting with 2.2.4 this will be supported, however, I don't know why after an "error" success is reported by git.exe.
On my home laptop with Windows 7 x64 (NTFS) some of mercurial repositories become stuck after unknown reason. The problem is when I try to run hg log or hg diff:
Can't access file
D:\user\my-hg-repo-root-path\='FRX'
In same time, icoming, pull, update, push, add, commit work well.
So, last several days i live without history or diff preview on the home laptop.
I've not found any reason for such a problem, as same as what FRX means. Do you know the reason of this problem?
PagerExtension?
That's where this ='FRX' might be coming from. Look at your ~/.hgrc.
It looks like this is a file that has been created by some windows application (from http://www.file-extension.com/files/FRX/: "As a binary form file, the FRX file extension can be found working with Visual Basic.") probably during an execution of VB programs, and it could be possible that you do not have the read rights on this file.
If this file is not important for you, I'd suggest to remove it from the working directory, maybe using admin rights.
I am using the newest GitHub for windows, and this occasionally happen
always suggesting I debug the repo in shell.
I am looking to learn how to do this debug
Is there any source that explains all (or even most) common problems that would cause this?
The repo seems ok when used from command line.
The specific case that is driving me crazy now is a Heroku project I'm trying to work on with a friend who uses Mac. Not sure if that is related, and I want to learn how to debug the general case, but any tips here would be useful as well
Running GitHub with administrator rights resolved the problem as well :)
You can find the "GitHub for Windows" log in
# WinXp:
C:\Documents and Settings\LoginName\Local Settings\Application Data\GitHub
# Or Win7:
C:\Users\LoginName\Local Settings\Application Data\GitHub
I have seen this message:
on authentication problem (I used it in a corporate environment)
when Windows keep an handle on some resources which should be updated by the git pull.
I usually keep a bash opened (launched from the "GitHub from Windows" GUI) in order to repeat the failed GUI operation as a git command.
I newly started working on Github via their native Windows Application, it's quite good however it's crashing so often and the horrible thing is that I lose all the recent changes after it's crashing. All the local files will rollback to the last version of the successful commit or sync.
I'm on a 64bit windows 8 machine. Any ideas?
The exact error after crash is Couldn't find a HEAD in this repository
I sent an email to GitHub For Windows support. Their answer was this:
Hi David,
I am sorry for the trouble.
I have been able to reproduce this problem, and have filed a report for our developers to look at. The reason the application is crashing is likely due to merge conflicts between the local and remote repositories.
The easiest way to resolve this would be to go into the repository that is saying 'failed looking for HEAD', closing that pop-up, and clicking Tools -> Open a Shell Here.
From the shell, you can run 'git reset --merge' to undo the merge that caused GitHub for Windows to crash.
From there, run 'git checkout master' to switch from the detached HEAD.
After that, run 'git pull' in the shell to pull down any new changes. It will prompt you to fix any merge conflicts (which is what caused the app to crash).
Once you fix the merge conflicts in the files, you should then be able to sync correctly in GitHub for WIndows.
I have been testing this issue, and after I resolved the conflicts with the initial crash, I no longer had any further trouble with GitHub for Windows. It correctly prompted me to open the shell and resolve merge conflicts rather than crashing.
Let me know if you have any further questions, and hopefully we will have a fix out for this soon.
Best,
Steve
This is the solution I received from Github support. I'll copy & paste the exact text here:
The easiest way to resolve this would be to go into the repository that is saying 'failed looking for HEAD', closing that pop-up, and clicking Tools -> Open a Shell Here. From the shell, you can run 'git reset --merge' to undo the merge that caused GitHub for Windows to crash. After that, run 'git pull' in the shell to pull down any changes. It will prompt you to fix any merge conflicts. Once you fix the merge conflicts in the files, you should then be able to sync correctly in GitHub for WIndows.
I have been testing this issue, and after I resolved the conflicts with the initial crash, I no longer had any further trouble with GitHub for Windows. It correctly prompted me to open the shell and resolve merge conflicts rather than crashing.
I had this problem after I made an unstable change to my .gitconfig user file.
I only detected the issue after I tried using TortoiseGIT and it outlined the error parsting the config file with an unexpected token.
So the fix was to correct the bad .gitconfig file.
Background: this is running on a Windows 2008 Server.
https://www.mercurial-scm.org/wiki/Workflows#Feature_separation_through_named_branches
I'm a Mercurial newbie, and am trying to follow the advice above where it says to "Merge default into your feature as often as possible" -- and I've done this a couple of times previously today, already, with other files.
However, this newest change just won't merge.
When I do the 'hg merge default' I get the error "abort: Access is denied". After googling around, I see that some people reported actually having permissions problems on the files in question. There's nothing special about the permissions on the file in question, at least not that I can see. I'm a Linux person by training, not a Windows person, so fundamentally I don't really understand Windows file permissions. Cygwin claims that the file in question is 644 (i.e., I can write to the file), which is the same set of permissions as every other file that has previously been successfully touched by the hg merge process in the past.
I took a look at the DOS 'attrib' command and it doesn't show a 'read-only' flag next the file in question, either.
If this is less a Mercurial question than it is a Windows permissions question, I'm happy to modify the tags further as well.
I'm assuming that this "abort: Access is denied" error refers to the file in the changeset that needs to be merged, and not to one of the .hg/ files, but it's a very cryptic error message -- it doesn't say which file has an access issue (and there is only one single file in the changeset that was changed -- I purposely tried to be VERY simple with this test).
UPDATE:
Did an 'hg rollback' and tried the same test of commands in the same order, leaving the files open, only with a completely different file (lib/blort.html instead of blah/foo.html).
The 'hg merge' worked just fine.
So there's probably something particularly hinky about the permissions on the specific file I started with (foo.html), or the directory that is its parent.
Another Edit
Definitely something off about the parent directory, as I had the same problem w/ another file in the directory, but the problem does not manifest elsewhere in the directory structure, only in this one directory.
Just checked the permissions on lib/ versus blah/ and they both seem the same in Cygwin, but that's only a vague approximation of the Windows ACLs. When examining those by right-clicking each directory and examining the 'Properties' Security tabs, they again seem the same for both directories, but I think the crux of the problem is that I really don't quite grok ACLs.
Is there some DOS command-line tool, like 'attrib' only more powerful, that, like 'ls' in linux, would give me more information than the confusing jumble of checkmarks I get in the 'Properties'?
Hopefully the final edit
How to diff Windows permissions
'iCacls' seems to be the correct tool for the job, and seems to have solved the problem, but I'd like to duplicate this before accepting/closing.
SUMMARY
When in doubt, use --debug on your Mercurial commands. This is a little bit 'duh' now, but thanks to #lazy-badger for pointing it out.
You can fix your Server 2008 permissions using a command like icacls path /grant domain\user:(OI)(CI)F (see e.g. http://www.petri.co.il/forums/showthread.php?t=23207), but be sure to do this from an escalated CMD window ('Run As Adminstrator'). Again 'duh' to Windows people, not so obvious to a Linux person (instead I went googling around for some DOS equivalent to sudo).
You may get an access denied error on Windows if some other program has the file open. You can try closing programs that might have any files in that tree open, or rebooting the computer (which would, of course, close all programs).
Just to note "Access denied" on merge can have two different roots: mentioned by #emil and wrong or nonexistent rights for user, under which credentials hg was started, to create temporary files in $TEMP folder