Empty or non-existent '/db/txn-current' in a Subversion repository

Question

I've encountered an issue with Apache Subversion repository and I'm looking for the best solution:

I can't commit to a Subversion repository and I'm getting the error:

svn: E720002: Commit failed (details follow): svn: E720002: Can't open file 'C:\Repositories\myproject\db\txn-current': The system cannot find the file specified.

If I create an empty txn-current file if will get another error on commit:

svn: E070014: Commit failed (details follow): svn: E070014: Can't read file 'C:\Repositories\myproject\db\txn-current': End of file found

NOTE: Let's imagine that I don't have a backup of a repository so I have to fix the issue manually.

The same behavior has been already discussed on StackOverflow: svn commit problem, Cannot read 'd:\UC\db\txn-current': End of file found. However I doubt that answers there are really helpful:

• I don't think that creating the \db\txn-current manually and putting a 0 there (or any other integer) is a good solution. I suppose that it could result into some unexpected behavior in near future,

• svnadmin recover and/or svnadmin verify do not create and/or populate txn-current. These commands are helpless in this case.

According to the FSFS description \db\txn-current file contains the next transaction key number. If I put some integer to the file then I can commit and the integer will increase by 1.

However looks like putting some irrelevant integer can break something in my repo and I don't want this to happen.

The "txn-current" file is a file with a single line of text that contains only a base-36 number. The current value will be used in the next transaction name, along with the revision number the transaction is based on. This sequence number ensures that transaction names are not reused, even if the transaction is aborted and a new transaction based on the same revision is begun. The only operation that FSFS performs on this file is "get and increment"; the "txn-current-lock" file is locked during this operation.

What should I do to fix the \db\txn-current issue properly? What integer should I put into the file? Is there any other way to solve this?

EDIT:

• How can I solve the same issue (non-existent or empty) but for db/current file?

Answer 1

In FSFS txn-current holds next transaction id. Transaction ID stored in revision itself after committing. So puttign really big number in txn-current should be fine.

Another solution would be to svnadmin dump repository and then svnadmin load it to fresh repository.

UPDATE: The issue with txn-current file corruption was investigated and in fixed in r1483781.

• fix repository corruption on power/disk failure on Windows (r1483781)

Fix is available in Subversion 1.7.10 and later.

Answer 2

I had similar problem. For resolving, I edited 'txn-current' file, put some large number say xxxxx in it. Along with it, I had to edit another file named 'current' in 'db\transactions' folder. I removed all contents from this file and just added a single enter and closed this file.

Answer 3

I was getting error as "Can't read 'D:\SVNROOT\UC\db\txn-current'.: End of file found" On probing further we realised that "Current" file in db folder was empty after some server OS upgrade activity. We found the latest revision number from revs folder and added the number into "current" file

It still did not work then we found this article which specifies that you have to put the revision number and then a "enter" after that

This works to resolve the error!

Answer 4

I had a similar problem, where a power failure occurred during a commit. I tried modifying the "Current" file but it did not work.

I made a backup of the repository, and then deleted the "current" file, and ran a "svnadmin verify" on the repository. Thereafter, I got the following error:

"Malformed file svn: Serialized hash missing terminator"

I then did a dump of the repository, deleted the old repository, recreated the Repository and imported the dump file.

Thereafter all worked well again. The full repository and History was still in place.

Answer 5

I did:

svnadmin verify /mnt/repos/
svnadmin recover /mnt/repos/

still got error...

svn: E000002: Übertragen schlug fehl (Details folgen):
svn: E000002: Kann Datei »/mnt/repos/db/txn-current« nicht öffnen: Datei oder Verzeichnis nicht gefunden

Then I created empty file: /mnt/repos/db/txn-current then svn ci worked again

If you don't want to wait:

svnadmin verify -r 997:HEAD <path>

is faster. exchange 997 with revision number, smaller than the bad revision

Answer 6

In my case. The VirtualMachine in which the SVN was setup, space was full. So cleaned up the space