I'm keeping my HG repositories on a NAS drive (QNAP TS-110, if that matters). The drive is running on some kind of embedded Linux, and both my computers are Windows machines (Win XP Professional and Win 7 Home Premium). Committing locally on my Windows machines works perfectly, but when I try to push to my "main" repositories on the NAS drive, I get a strange error most of the time (no matter if I do it from the XP or the Win7 machine). Sometimes (but not often) it works. Here is an example: First, I create a repository on the NAS drive (drive Z:) and a local one, commit a file to the local one, and try to push to the remote one: md z:\hg\remote hg init z:\hg\remote md c:\local cd c:\local hg init echo foo >foo.txt hg commit -A -m "first commit" hg push z:\hg\remote The push command outputs the following: pushing to z:\hg\remote searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files abort: z:\hg\remote\.hg\store\.fncache-9kpz7y: Zugriff verweigert ("Zugriff verweigert" is German and means "Access denied" or "Permission denied") After that, I check the remote repository: z: cd hg\remote hg log hg verify hg log outputs this: changeset: 0:fabcccc99fad tag: tip user: Christian Specht date: Fri Jun 17 21:56:06 2011 +0200 summary: first commit .. and hg verify outputs this: checking changesets checking manifests crosschecking files in changesets and manifests checking files 1 files, 1 changesets, 1 total revisions data\foo.txt.i@0: missing revlog! 1 integrity errors encountered! (first damaged changeset appears to be 0) So the changeset was pushed to the remote repository, but it's somehow damaged. But it doesn't seem to be THAT damaged, because I'm able to clone the remote repository after that. I'm using Mercurial 1.8.4 at the moment (with TortoiseHG 2.0.5, but there is no difference whether I try pushing from TortoiseHG or the command line). But the problem is not specific to version 1.8.4, because I'm having this problem for a few weeks now (unfortunately I don't exactly remember when it started, probably somewhere around 1.8, but I'm not sure anymore). Plus, it seems to be a Windows <--> Linux issue, because it only happens when I push to the NAS. I can push to other repos on the local machine without problems, as well as to the other Windows machine over the network. At my workplace, we are pushing to a network share on a Windows server as well and never had any problems. And it can't be a permission issue, because my Windows user has full write access to the NAS. I can copy files to the same folder without problems (that's what I'm doing at the moment when pushing doesn't work: I always copy the whole .hg folder manually from the local machine to the NAS).
Please try to run the push with --traceback. Notice the warning on http://mercurial.selenic.com/wiki/PublishingRepositories : "shared disk: not generally recommended due to general issues with network filesystem reliability". Another reason is that Mercurial is strictly backward compatible over the network protocols but might introduce new file system formats that older Mercurials can't access directly.
C:\local>hg push z:\hg\remote --traceback pushing to z:\hg\remote searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files Traceback (most recent call last): File "mercurial\dispatch.pyo", line 58, in _runcatch File "mercurial\dispatch.pyo", line 601, in _dispatch File "mercurial\dispatch.pyo", line 406, in runcommand File "mercurial\dispatch.pyo", line 655, in _runcommand File "mercurial\dispatch.pyo", line 609, in checkargs File "mercurial\dispatch.pyo", line 598, in <lambda> File "mercurial\util.pyo", line 433, in check File "mercurial\commands.pyo", line 3028, in push File "mercurial\localrepo.pyo", line 1431, in push File "mercurial\localrepo.pyo", line 1918, in addchangegroup File "mercurial\lock.pyo", line 127, in release File "mercurial\store.pyo", line 345, in write File "mercurial\store.pyo", line 278, in write File "mercurial\util.pyo", line 911, in __call__ File "mercurial\util.pyo", line 834, in __init__ File "mercurial\windows.pyo", line 20, in posixfile IOError: [Errno 13] z:\hg\remote\.hg\store\.fncache-u1_okj: Zugriff verweigert abort: z:\hg\remote\.hg\store\.fncache-u1_okj: Zugriff verweigert (As I said before, "Zugriff verweigert" means "Access denied" or "Permission denied".) > Notice the warning on > http://mercurial.selenic.com/wiki/PublishingRepositories : "shared disk: not > generally recommended due to general issues with network filesystem > reliability". Yes, I read that. But unfortunately, shared disk is the easiest way to setup for private use. The web server stuff is overkill for private use by a single person, and most of the solutions require Linux knowledge which I don't have. (My NAS is actually able to run a Linux web server, but with absolutely NO knowledge about Linux or web servers, I seriously doubt that I would get HG to work on that.) Adrian Buehlmann wrote me a mail and suggested putting my stuff on Bitbucket instead. If I can't get HG to work with the NAS, I'll probably do just that. > Another reason is that Mercurial is strictly backward > compatible over the network protocols but might introduce new file system > formats that older Mercurials can't access directly. I don't think that this causes my problem. Look at the example that I posted in my initial bug report: I push with the EXACT SAME Mercurial installation that I created the local and remote repositories with, so it can't be an issue with older Mercurial versions.
Mercurial can for some reason not create this temporary .fncache-something file. Can you create it manually? It might however be caused by some timing issues that are hard to reproduce - for example some scanner or indexer that interferes somehow. Some kind of trace of file system access might give a hint what is going on. It might prove that the NAS just doesn't behave as it should.
The file already exists immediately after the push, but it's empty. I tried to write to it with two different text editors: Windows Notepad is able to save, Notepad++ is not. Very strange. Maybe different programs write to files in different manners? No idea. I guess Mercurial creates the empty file first, then tries to write to it (but isn't able to). I'll try to find a possibility to trace file access...
I'm surprised that you guys still spend time on this. I'm really tired about these Windows share thing, and this NAS thing surely adds some really funny (aka stupid) behaviors on top. If you still want to keep playing (I don't): I noticed that Christian's error message matches case 2b on http://mercurial.selenic.com/wiki/UnlinkingFilesOnWindows (calling "fd = posixfile(f, 'w')" on a ghost file name). So it might be that something is holding such a temp file name in scheduled delete (holding it open and thus delaying it's complete deletion) while mercurial tries to create a file with that name again. On real Windows shares (served by Windows) there doesn't seem to be a problem (never heard of others having problems doing that).
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:20 EDT --- This bug was previously known as _bug_ 2857 at http://mercurial.selenic.com/bts/issue2857
Bulk close: no activity for >2 years -> WONTFIX
Bulk change recent WONTFIX -> new, more descriptive ARCHIVED state (sorry for the spam)
Sorry, for resurrecting this old thread, but I'm facing the very same issue. I have a hg repo, which I try to push/clone to a FreeNAS shared folder. Mercurial fails with the same error: Z:\>hg clone \\originalrepo clonedrepo requesting all changes adding changesets adding manifests adding file changes added 136 changesets with 24565 changes to 23597 files (+1 heads) updating to branch default abort: Z:\clonedrepo\fix_bat_encoding.ps1: Access is denied I have read/write permissions over the shared folder. Tried a clone, push+update and the result is the same.