Update and Cleanup failing constantly from one client computer and working from others

[Jack Lewis]

I am running Windows 10 Pro with a desktop and have also a laptop I work from. 

Right now every time I do an update with my desktop and some files were changed on the server and need to get updated, I can see the files getting updated in the tortoise SVN UI, followed by a delay of maybe 10 seconds and then always get the  "Failed to run the WC DB.... Access Denied".

The only way I can get out of this is to go on my laptop and perform the exact same operation which works from that system all the time..

I have tried disabling my anti-virus (the same I have been using for years without problem), I've even uninstalled it. I have uninstalled all the windows apps that I wasn't using regularly just in case.

I've downgraded TortoiseSVN, re-installed.... I'm basically running out of ideas.

I am using the same account on both my desktop and laptop and the same samba share on both systems. I've run out of ideas in terms of how to find the root cause of this problem.

I am right now using TortoiseSVN version 1.13.1 64 bits.

I even took SMB captures with wireshark when doing the successful vs the failed update and it looks like tortoise SVN is trying to rename the updated file that it got from the server in the .svn tmp folder to the normal location when the file is still there which generates a SMB collision error.

On the laptop the destination file is deleted right before the tmp file is renamed with the correct path and name.

I have no idea why on one system it does the correct sequence, delete destination than rename to that destination and not the other system.

[Stefan]

don't do that:

https://tortoisesvn.net/faq.html#wconshare

so: do a fresh checkout on your local drive and then throw away the working copy on your share.

if you don't, you will lose data.

[Jack Lewis]

And how do I go about running my linux cross compiling tools on that windows local drive then?

I and a team of 10 devs have been using a linux hosted SVN server accessible via SAMBA for over a decade without any problems till a month ago.

If I didn't have to use a SAMBA share, I wouldn't be using one.

[M. Ziggy]

My two cents... It may be an issue with drive formats/drivers. Desktop is probably the NTFS6 driver now (where Samba expects 5 or earlier), and many laptops/tablets/phones use EXFAT instead of NTFS. Using a USB drive, formatted to EXFAT with 4k or 8k clusters, to hold the WC may be an option. If a share of this isn't directly accessible to the cross tools, an export from there to main drive should be.

[Niemann, Hartmut]

Hi Jack,

 

can you describe your setup in more detail?

 

1. there is an urgent recommendation not to share working copies. Give each OS and each user his/her own, and some problems should go away. And just to make sure, don’t put them on a shared file space if your local drives have enough capacity.
2. you can and probably should use a network protocol like http: or svn: if you connect to a repo on a different host and not share the repo on a network drive. If the data is on Linux already, this should be not more than looking up how to run subversion in server/daemon mode.

 

Hope that helps.

Hartmut

--
You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/5bd70a86-8ed8-4544-be24-80187b186b37%40googlegroups.com.

[Jack Lewis]

Thanks for the response, there was no sharing of working copies involved. The working copy was on a SAMBA share due to the editing and general dev work happening from windows, while the compiling was done on a linux server with a cross compiling tool chain.

Anyway, I found the root cause today.

Turns out it was the anti-virus, Kaspersky which had been updated in februrary.

The initial uninstalling that I had tried back when the problem initially showed up didn't properly get rid of ALL it's components. 

Namely there was a file system filter driver that was left over and could be seen via the fltmc command.

I uninstalled the anti-virus again but using a special removal tool they provide on their web site instead of the usual control panel add/remove programs option. I rebooted and presto tortoiseSVN is back to working perfectly like it had for years before.

I had doubts about other things too since my desktop had gotten upgraded from windows 7 to 10 a few weeks prior but it was the anti-virus all along. So now it's their turn to get a support request!

To unsubscribe from this group and stop receiving emails from it, send an email to torto...@googlegroups.com.