Our issue tracker is now located on Google Code This page isn’t used anymore and only still here to keep the old issues around.
FS#188 - Cache prevents drives from being ejected properly
Attached to Project:
TortoiseSVN
Opened by Stefan Küng (steveking) - Sunday, 20 November 2005, 11:58 GMT+2
Last edited by Stefan Küng (steveking) - Thursday, 20 September 2007, 19:49 GMT+2
Opened by Stefan Küng (steveking) - Sunday, 20 November 2005, 11:58 GMT+2
Last edited by Stefan Küng (steveking) - Thursday, 20 September 2007, 19:49 GMT+2
|
DetailsThe cache holds a drive handle open on each watched drive. But open handles prevent Windows from ejecting drives (e.g. USB memory sticks). An error dialog is shown that some applications still have files open on that drive, and ejecting fails. We have to register for device change notifications, then when a WM_DEVICECHANGE message arrives with the correct param we must close those watcher handles immediately so that Windows can eject the drives. Hmm - what happens if the crawler is still crawling that drive? We\’d have to stop the crawler too, which might not be possible in the short time Windows gives us... |
This task depends upon
Closed by Stefan Küng (steveking)
Thursday, 20 September 2007, 19:49 GMT+2
Reason for closing: Implemented
Additional comments about closing: Done in revision 10682.
Thursday, 20 September 2007, 19:49 GMT+2
Reason for closing: Implemented
Additional comments about closing: Done in revision 10682.
Please reopen, because the solution does not always work.
Unfortunately, I currently cannot exactly specify how to reproduce, however I frequently have the problem, that an USB device cannot be ejected cleanly after copying a couple of files to it (by Total Commander, for instance). When I kill the cache process in this situation I’m immediately able to safely remove the hardware.
Any suggestion what I can try in such situation?
Furthermore, although this might be a driver specific bug, I have the very same problem with the ImDisk virtual hd driver (www.ltr-data.se/opencode.html#ImDisk). This one can be easily reproduced: mount hd, right click a file on this virtual drive, try to unmount hd - does not work until killing cache process.
And I seem to remember having had such problem with Truecrypt (www.truecrypt.org).
One way to at least reduce such problems:
don't watch drives which don't have any working copies on them.
The cache could prevent adding paths to the watcher if it doesn't know at least one working copy which is on the same drive.
Implemented the reduced watching in revision 10682.
There's not much more we can do.
We already handle the drive notifications which the the hd driver sends and close all our handles. But if the hd driver doesn't send those notifications, then that's a bug in the driver and we can't do anything about it.
For all those who suffer from this problem:
The hd driver must broadcast a WM_DEVICECHANGE message to all registered applications with the DBT_DEVICEQUERYREMOVE flag set. That gives the applications the chance to close open handles on that drive. This message must be sent when the user requests to unmount/eject the drive. Of course, the driver must give the applications some time (MS recommends 2 seconds, which it does for e.g. USB drives itself) to actually close the handles.
AFAIK, truectypt has a new version out which now sends those messages and therefore shouldn't have that problem anymore.