Gleason, Todd wrote:
> Just saw this with 1.4.7:
>
>
>
> 1. TSVNCache was running. It was configured to include paths C:\rd*
> as well as a few others.
> 2. Renamed directory from C:\rd to C:\rds.
> 3. Tried to rename directory again. Failed.
> 4. Opened Process Explorer and scanned for C:\rds handles.
> 5. Only 2 processes had it: explorer.exe (which is what I was using
> to rename the folder with—so this one is safe), and TSVNCache.
> 6. TSVNCache actually had locked a directory immediately under,
> C:\rds\Run, which was completely empty. It was sitting there with
> the lock open for no reason I can tell. Waited, re-scanned, and
> it still had it open.
> 7. Tried again and still failed to rename the folder.
> 8. Went to TortoiseSVN->Settings, Icon Overlays, changes Status cache
> from Default to Shell.
> 9. Waited a few seconds. Handle gone. (TSVNCache gone, of course.)
> 10. Renamed folder.
> 11. Changed Status Cache back to Default. Waited a few minutes.
> Verified TSVNCache is back.
> 12. Renamed a few more times, and it’s okay, but Process Explorer now
> shows “Non-existent process” as having a lock to the top-level
> directory there. Even so, I can still rename the folder. I’m not
> sure if this is some remnant of TSVNCache, something from Windows
> Desktop Search, or what.
>
> In any case, it seems to me that TSVNCache can sit around, locking up a
> folder and preventing its parent from being renamed, but the behavior is
> not readily reproducible.
The cache does not really lock the folders. It keeps a handle open on
those folders to watch them for changes. Those handles have full shared
rights set, but apparently that's not enough to let other applications
rename or remove the folders :(
I'm not sure how this can be avoided though.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-02-13 18:45:25 CET