Torrent stops with file access error, though no sharing violation

[db90h]

Hi,

Great work on uTorrent . I have run into a bug in the v1.2.2 and v1.2.3 beta. Periodically the download of a torrent will stop with a file access error. There is no other external use of the target file(s). No anti-virus software or other external programs are accessing the files, they do not have read-only attributes (unless uTorrent is setting them), and certainly aren't on read-only media.

A couple conditions I normally have uTorrent running in are (not necessarily related to errata):

1.) Often switch file priorities, including 'don't download' status.

2.) Often stay in file view.

3.) OS: Windows XP x64

4.) No AV software or other file system filter devices.

Perhaps its a thread-synchronization error; I dunno.

UPDATE: I have discovered that setting disk_io.flush_files to false appears to fix the issue.

Am I the only one who has seen this?

Again, great work. And thanks .

db90h

[luispic]

nope you are not the one having that problem, it has also been discused here: http://forum.utorrent.com/viewtopic.php?id=1407&p=1

it seems to be some kind of trouble with the google desktop or some indexer program do you have one installed?? i had google desktop running.

[chaosblade]

Basiclly, uTorrent closes the handles to that file (flushing, to reduce memory caching, alot of reasons really) then another process\application 'steals' the file and locks it.

Im not sure what can be done about it, really.

[Firon]

turning off flush files fixes it, it's the only thing you can do

[db90h]

I do have Google Desktop running, I had not even considered this.

But any interoperability between uTorrent and Google Desktop is surely caused by uTorrent. Google Desktop should open files with full sharing allowed (read,write, delete). I suspect uTorrent is opening the files without even read sharing permission, causing the error. I can't imagine for what reason not allowing read sharing would be warranted, but there may be some rationale for this.

Anyway, keeping flush_files turned off is fine in my case.

Thanks

[Firon]

You can't read a file that's being written. You can't write to a file that's being read. µTorrent HAS to open the files exclusively for it to work.

Flush files closes open file handles every minute to prevent the Windows system cache from using all the RAM (people kept complaining about a 'leak'), which causes a problem with Google Desktop since it's always trying to read the files. At the minute point, Google Desktop will grab that file that was released and read it, which prevents µT from writing since like I said before, you can't write to a file that's being read.

It's not really either program's fault, though I do think Google Desktop is useless. =P

Excluding the download folders should work too though, allowing you to reap the benefits of flush files.

[db90h]

Actually, there is no such read/write exclusivity built into win32. Although that sounds intuitive, its not the case. Its all in the sharing access provided in the call to CreateFile. So, it doesn't have to have them opened exclusively.

Oh well.. just letting you know.

[Firon]

Well, if it's not required, there must be a practical reason for it then, since just about everything opens the file exclusively when writing.