Failed to run the WC DB work queue associated with file

Without thinking I added and committed a file through my osx system that had a question mark in it not thinking about how this would impact windows. On windows when I did the update it failed because it was unable to create a file with a ? in it so I went back to my osx system and did an svn rename on the file however on windows this did not help since svn goes through the history of all steps to bring a workspace up to the head revision. Needless to say I am stuck, any ideas how I can fix this?

Here is my current svn error log when updating (tried using Tortoise SVN and command line, both are the same):

svn: E155009: Failed to run the WC DB work queue associated with 'F:\Devel\bc\dev\trunk\appShare\media\frontend?_12x15.png', work item 53314 (file-install appShare/media/frontend/?_12x15.png 1 0 1 1)
svn: E720123: Can't move 'F:\Devel\bc\dev\trunk.svn\tmp\svn-68A36D23' to 'F:\Devel\bc\dev\trunk\appShare\media\frontend?_12x15.png': The filename, directory name, or volume label syntax is incorrect.

Each time I do this I have to delete the records in the WORK_QUEUE table in wc.db and then do a cleanup before svn will let me try something else.

Thanks to this reference for a solution that worked on Mac with svn installed via brew.

cd {work-dir-base}
sqlite3 .svn/wc.db "delete from work_queue"

Here is another blog entry dealing with this issue.

These are the steps that I did to get rid of this error

1. Download sqlite from https://www.sqlite.org/download.html, download the Precompiled Binaries for Windows. I downloaded sqlite-tools-win32-x86-3200100.zip which contains the .exe of sqlite

2. Extract the zip and add the path where you kept the sqlite3.exe to your windows PATH variable.

3. Now navigate to the location of your .svn directory

4. Open in command window and execute the sqlite3 .svn/wc.db "delete from work_queue"

5. Now go ahead and run your svn cleanup, everything should work fine.

For Windows users.

1. Copy sqlite3.exe where .svn directory exist.
2. Open CMD as admin
3. commands :

	C: sqlite3 .svn\wc.db 
	sqlite> select * from WORK_QUEUE;
	sqlite> delete from WORK_QUEUE;
	sqlite> .quit
	C: svn cleanup

That is to delete the folder through svn on the windows box that contained the badly named file. This must tell svn to not bother updating that folder if it sees a local delete that has not yet been committed. If you do this be sure to back up your files first so you can recreate the folder and add all the files again (named properly of course).

In concrete terms:

1. SVN Rename file on other machine to right filename
2. SVN Delete the folder that contains the badly named file on the Windows machine.
3. Update your working copy, this will now work fine.
4. Resolve the conflict between renaming and deleting.
5. Revert your local modifications (SVN delete, which has not been committed yet).

Creating an .svn/tmp directory solved the issue, in my case

I have also faced a similar problem:

I have deleted a local folder (for which svn files were checked out). After this none of the svn commands were working fine, even from cmd prompt(admin), also svn cleanup was not working.

Fix:

1. I have created a dummy file, for which the error 'svn: E155009: Failed to run the WC DB work queue associated with' is coming.
2. Then I have run svn cleanup in cmd line, found the same error in that a file couldn't be read
3. Repeated the above steps for the file not found in step2.
4. svn cleanup, it works!

Closing all the visual studio instances fixes the problem to me.

We ran into this issue because MalwareBytes Ransomware Protection was turned on along with a few other MalwareBytes components.

Others have reported that Bitdefender caused this issue as well, on both MacOS and Windows.

The actual error we saw was

> Can't move 'xxx' to 'yyy': Access is denied.

It also broke the ability to run a cleanup operation.

It seems to be a race condition -- the offending file changes each time. Disabling the Ransomware Protection component resolved the issue.

Just delete .svn\tmp in the workspace.Did work for me.

Another way to resolve this issue. What is happening is the SVN is trying to perform an action (WC database), but for some reason that action did not finish properly, so it throws an error. You can try to have it finish the action by replacing the file, or make a dummy file that it complains about and then do an SVN clean, and update/commit, or what every you were doing.

I just opened the file in notepad ( a .less file in my case ), gave it a modification ( enter for instance ) and saved the file. After that i was able to clean up.

To solve the issue in windows 7, let's say in your folder X that won't cleanup there is another folder called A in which the issue appear. Just checkout the folder A elsewhere and copy it back (of course without .svn cached folder) to X and then run cleanup and update etc.

I figured out I was getting this issue because some CLI process was using the file and it was blocking access to it. In my case a background job in a Laravel queue.

I know this is an old issue but, in my case, there was another issue not mentioned in any of the other answers.

When pulling from a Unix server on a Windows machine you might ( sometimes ) get files or folders with the same name but different casing.

In my case it was failing at a folder Sanitize.js and a file sanitize.js.

To get around this I decided to make the work directory case sensitive by following this and this

Cleanup and update worked as they should afterwards.

This occurs when one of your file from that folder is in use. Generally the file is being used by a process like EXE or some task which runs concurrently on your system.

svn: E155009: Failed to run the WC DB work queue associated with "some-bad-file" work item "file-number" file-install "some-bad-file 1 0 1 1" svn: E000022: Can't move "version-of-file-in-.svn/tmp" to "some-bad-file": Invalid argument

I recently had this issue on Kubuntu 20.04. There was a bad filename that was a result of my running a script to bulk rename files in an svn folder. I got it working without needing to access the repo machine as follows:

1. Copy bad filename from error in command-line (in my case, there was a colon I added from when I added the file using TortoiseSVN in Windows).
2. Copy and rename "version-of-file-in-.svn/tmp" appropriately
3. run the commands stated in @PipoTells answer. The same works with Debian flavours because sqlite3 comes preinstalled, at least for Kubuntu 20.04 as far as I know.
4. Delete the badly named file: "svn delete path/to/bad-file-name.extension". It doesn't seeem to matter that the file is not in your working copy at this point. The command is still sent to the repo machine and executed on commit.
5. "svn add path/to/correctly-named-file.extension"
6. "svn commit" and "svn update"

I hope this will help anyone else who comes accross it.

I was able to fix it thus:

1. Right-click on the item, click on "Tortoise SVN -> Update to revision"
2. The item will be deleted
3. Run SVN cleanup
4. The file will reappear

Svn uses a database in the .svn folder to help itself track work in progress and assist it in doing rollbacks, etc. Unfortunately, if you can crash svn in just the right way it can quit where it thinks a file has been created and it needs to set permissions on it, but it never quite created the file (on Windows).

As the above answers describe, you can use sqlite's command shell to fix this. But the changes are far higher than you have Python available to you, and sqlite3 is one of python's built-in packages, so you can usually fix it as follows:

# cd to top of working copy
python -c "import sqlite3" -c "db = sqlite3.connect('.svn/wc.db')" -c "db.execute('DELETE FROM WORK_QUEUE;')" -c "db.commit()"

Delete the file that was causing the issue and then do a clean up. This will fix the issue