• DiagnosticMessages

Diagnostic Messages

This page is for documenting the meaning of all the diagnostic messages that darcs produces. Once answers are refined here, perhaps they will be added to the official documentation.

To a great extent, this page is obsolete. A lot of effort has gone into making Darcs emit user-friendly error messages since 1.0.6 or so, and we hope that you no longer find error messages confusing. If you do, please do file a bug report.

darcs failed: Couldn't commute patch past pending.

Darcs couldn't deal with the pending differences, i.e. the differences between what's in the working dir and what's in the repo.

It's possible to receive this message when unpulling a patch that has conflicts it. To fix the situation, you may need to edit the conflicting patch by hand, or run 'darcs revert', which removes changes in the working directory (and hence might discard some of your work!).

To avoid the error in the future, you could make sure all changes in the working directory are recorded before pulling a patch. You can check that you are in this state by running 'darcs whatsnew' and verifying that it reports "No changes!"

Error applying patch to recorded!

This can be returned when you are pulling, and is a possible sign of an inconsistent repo. Running darcs repair may help.

I got this message using 'push' for a new patch. The problem was that I had accidentally edited a file in the _darcs/current tree. I unrecorded, repaired the edit by copying the version from another repository, re-recorded, pushed, and all was well. --RobGiardina

I got this error when pushing from case-insensitive file system (Windows) to case-sensitive one and the corresponding files had different cases and for some reason this caused an error. Fixed by wiping local repository and getting remote repo and then recording the change again.

Fail: Couldn't read patch

This message may be returned by any command that tries to read the patches in a tag. The error message should be more explicit about the cause -- but it currently isn't.

Is there any hope to recover from this condition? --MarkStosberg

Depends on the cause of the error; unfortunately, current Darcs doesn't tell you why it couldn't read the patch. -- JuliuszChroboczek

Fail: /usr/tmp/darcsyZoD7A: openBinaryFile: does not exist (No such file or directory)

With darcs 1.0.3, this was seen when using darcs diff -u -p patch_name, when the diff binary it was looking for could not be found. A future version may give a more informative message is this case.

This might also happens when pushing binary patches if your /usr/bin/diff does strange things, like the one shipped with Mac OS X. Edit your $PATH so diff from darwinports or fink is used or compile from source to fix this.

Fail: .../_darcs/inventory: openBinaryFile: does not exist (No such file or directory)

You will see this message when you try to 'push' to a location that is not a repo. Don't do that.

If you see this message when using 'send', darcs is trying to send to what it believes is the last remote repository you used, and failing. It won't ask for another repository even if you specify the interactive option; you have to pass one as an argument. If all else fails, create a new directory with an empty darcs tree (darcs initialize), and send to that: this can be useful if you just want to get your patches out of the repository using -o.

Copying patch 938 of 4881...darcs: ...gz: openBinaryFile: does not exist (No such file or directory)

You could see this this message when calling "darcs get" on a partial repository. One solution is to add "--partial" to the command. For "darcs-2" format repositories, this issue no longer comes up-- the command succeeds.

Fail: <stdin>: hGetChar: end of file

This can happen with darcs record.

It can be caused by piping data into it when it expects to work interactively. Here's a workaround if you are trying to pipe in a list of files to record like this:

$ find . -name '*.cgi' | grep www | xargs darcs record

Better yet, you can achieve the same thing like this, and still work interactively with record:

$ darcs record `find . -name '*.cgi' | grep www`

Fail: Failed to create temporary file darcs: permission denied (Permission denied)

I got this message using 'push' with darcs 1.0.0. The problem was that I didn't have permission to write in the root directory of the target repo. --MarkStosberg

I get this while running darcs get. I have permissions in the repo beeing created (of course), and I shouldn't need _write_ access to the original repo, right? Maybe this is because darcs tries to hardlink files when the repos exists in the same file system? --RasmusKaj

Try upgrading to darcs 1.0.2. There's a bit of ChangeLog that says * Fixed bug which caused a crash on a local get of a repository owned by another user.

Fail: bug in get_extra.

The error message refers the user to a bug in 1.0.1 (see Issues1.0.1). DavidRoundy writes to darcs-devel:

• The bug message really should be updated. It's not the 1.0.0->1.0.1, but rather an existing bug in merger commutation, which can be triggered on the darcs repository (usually when patches sent to darcs-stable to darcs-unstable). :(

  It's possible to work around this bug by reordering the pulls/pushes. You can try getting a copy darcs-unstable, pulling your patch into there, and then sending from that repository to darcs-unstable. That has worked for me in the past.

Waiting for lock ..

Followed by "Couldn't get lock", see below.

Couldn't get lock .../lock

This means that darcs tried to access a repository that is locked, i.e. marked as being currently accessed by a different copy of darcs.

If you are confident the repo shouldn't be locked (there's no other copy of darcs running), you can unlock it manually by deleting the lock file _darcs/lock. Then, run darcs check.

Skipping depended-upon patch

This can be emitted by unrecord if using the --patch option has found a match that is depended on by other patches. TODO: How can you find out which patch?

Skipping 'foo/boo/import_photos.pl' ... parent directory 'foo/boo/' isn't in the repo.

You will see this file if you try to darcs add a file in a directory that hasn't been add ed yet

You need to either add the parent directories manually, or use darcs add -r in a high enough directory to add them all. To add the directories manually, you have to add the top most directory first, like this:

$ darcs add foo
$ darcs add foo/boo

Newer darcs versions (> 1.0.2) automatically add parent directories. If you get this message with such a darcs version, please report it as a bug.

Fail: takeLock foo.txt-0: permission denied (Permission denied)

This may indicate a file system permissions problem in _darcs or your working directory. This diagnostic message provides much improved feedback in Darcs 1.0.3 and later.

Yikes! conflicts in pending

This is a bug in darcs and never happens I believe there is code in 1.0.0 and beyond to check for this and emit an error just at the moment the condition is created. Thus, if the bug still exists, it should now be easy to pin-point where it's coming from and provide a long term fix.

Unable to apply patch!

This message means that a patch that darcs decided to apply doesn't apply cleanly to a repository. Either your repository is corrupt (run darcs check), or you've found a bug in darcs. In either case, you're in trouble.

darcs failed: Unable to apply inverse patch!

This is similar to the above, but means that it is the inverse of a patch that darcs couldn't apply (for example, when doing unpull or rollback).

darcs failed: Unapplicable patch! (during a 'darcs check')

This means that while darcs was trying to re-apply all the patches in your inventory, it found one that doesn't fit! This basically means your inventory file is corrupt. (Interestingly, darcs can continue to add new patches to a repository with a corrupted inventory file with no side effects. However, things explode when you try to push or pull.)

First, try to think of anything that would have rewritten your inventory file, and don't do it in the future

Meanwhile, rebuilding your inventory isn't impossible: I use something like

$ cd /path/myrepo/_darcs
$ mv inventory old_inventory  # save it, just in case
$ ls patches/*.gz | while read fname; do # for each patch...
     # grab all the lines up til "] {", and trim off the "{"
     zcat $fname | sed -n '0,/] {/p' | sed 's/] {/]/' >> inventory;
  done

If your inventory contains only valid, needed, patches, then everything is fine. Run 'darcs check' to find out. However, chances are that you've unrecorded or amend-recorded something, and in my experience, these patch files remain in '_darcs/patches'. Now, they're also listed in the inventory again; that means you'll have unapplicable patch errors still.

To find these conflicts, and remove them:

• Make a new repo directory and run 'darcs initialize'
• Then, try "darcs pull /path/myrepo" and pull one patch at a time
• When darcs says "Error applying patch to recorded", you need to decide (by looking at the name, or contents of the patch) whether that patch belongs, or not. If it does, then look back a few patches and look for a patch which you've unrecorded in the past. When you find the one that doesn't belong in the repo, go back to your new inventory file and remove those lines that list it.
• Resume pulling patches one at a time into the new repo
• Once you successfully pull all the patches in the trimmed inventory (and assuming you get your data files back the way you expect it) then you're done!

Keep in mind:

• You probably don't want any conflicts in your temporary repo. Use unpull liberally, followed by changes to the inventory file in the main repo, followed by pull again.
• Once you get everything fixed, you might want to wipe the patch files that aren't being used. Simply pull to a new empty repo (which will only copy patches in the inventory) and then delete the old repo and use this one in its place.

Fail: takeLock .../_darcs/lock in ...: failed (Unknown error: 0)

I got this error working in a repository on a FAT file system (on a USB stick) on a Mac OS X machine that had a hostname containing colons (not my choice). It appears that darcs' locking mechanism creates a temporary file whose name contains (part of) the hostname. On a FAT file system, file names can't contain colons. Since my hostname did, darcs was unable to create the lock.

My workaround was to set the environment variable DARCS_SLOPPY_LOCKS. This makes darcs use a different method of locking the repository that is not safe over NFS (but perfectly safe on any half-reasonable implementation of FAT, which I assume includes Mac OS X) but doesn't suffer from the above problem.

A better solution might be to modify the function careful_atomic_create() in compat.c to somehow treat colons in hostnames specially. This is issue 163.

Heap exhausted; Current maximum heap size is 268435456 bytes (256 Mb)

I got this error on win32 pushing a 394MB local repo with text and large binary files to an empty local repo. The error follows up with use `+RTS -M<size>' to increase it. This doesn't completely describe the commandline to fix this, since you also need to mark the beginning of the command line args. A complete command would read something like darcs +RTS -M512M -RTS push <YOUR_REPO>

---

Comments

I'm thinking we might need a new page on "How to recover severely broken repos by hand". I think the section on rebuilding the inventory doesn't really belong here, but I didn't see any better place to put it. --Mike Conrad

Perhaps later these messages can be organized according to which commands can emit them. -- MarkStosberg

No, they couldn't -- most of them can be generated by multiple commands. For example, unable to apply patch can happen in any of the commands that record patches -- basically any darcs command.