Error: Access denied.

[DutchDude]

I keep getting this error with 1 of the torrents. The problem is it doesn't specify what exactly is wrong. My best guess is that it fails to access a local file, but the torrent has so many files that i can't be sure which file is causing the torrent to stop. Even the 'logger' does not give out any additional info.

Is it possible to change the program in such a way that at least the Logger tab ouputs more info regarding any errors that may occur (for example the filename) ?

Is it possible to change the program's behaviour that when a file could not be accessed the file is set to a special status (hence ignoring the file) and keep the torrent downloading other files ? At this moment the torrent simply stops....

Again, i'm just guessing that there is a problem with 1 of the files...... there is no way for me to be sure that this is actually the case.

[DutchDude]

I can definately rule out that is has anything to do with local files.....so i'm baffeled what's wrong...... logging to the 'Logger' tab would still be helpfull...

Btw: the version is 1.2.2

[Don't quote yourself...]

[Animorc]

This is because the files are marked as read-only in the Windows filesystem. Are you using the latest realease of µTorrent? I thought it was fixed.

P.S. Why quote yourself? o.O

[DutchDude]

Well.... i sometimes speak to myself when i'm baffled about something

As said in my edit: it seems it has nothing to do with local files. Currently i'm under the impression that when a tracker could not be contacted (update failed) the torrent is stopped.... in version 1.2.1 the download continues, but in version 1.2.2 the thing starts, downloads a few files/parts, then stopps with the given error. I noticed that the tracker timed-out.... so this leads me to believe that somehow the torrent is stopped if it fails to contact the tracker for updating....... (btw ... i have never maxed-out ... but currently this is the case, so perhaps it is somehow related to this problem occuring.... (actually 1 torrent is maxing out my download speed)

edit:D%^&.... the problem now also occurs in 1.2.1, but it takes a bit longer.....

[don't double post, use edit]

[chaosblade]

Something else on your computer is doing something to those files. (MSN desktop, google desktop, AV scanning or indexing?)

[DutchDude]

After running 'attrib *.* -r /s' in the folder the problem disappeared (this command removes any read-only flags on files), allthough the download went significantly down, so it could still be a comby of things....

AV System Scanning has allways be running, as for desktops & indexing are never used on my system.... i hate those...

Any way.... the problem went away as soon as the download speed went down and the file attributes were reset. No idea what the exact problem was, which brings me back to the logger.... can it be made in such a way that all errors are logged verbose, instead of not displaying anything or just being to vague ?

Thnx,

BTW.... still is the best client around... even with these minor problems........

[Firon]

Read-only will screw up downloading (logically, it can't write if it's read only!), but not seeding.

[chaosblade]

Actually i remember a person having this issue while seeding, he removed the read only attribute and it worked for him too.

[Firon]

That was a while ago, and it was fixed. It was DomZ by the way.

He was trying to seed off a CD, and while I'm not sure if that was fixed, the read-only error while seeding off an HD was fixed for sure.

[chaosblade]

Nope, not domz. I remember a diff. guy, italian or something along those lines (since his english wasnt amazing and he kept apologizing for it). He simply put his files to read only on purpose for whatever reason.

[DutchDude]

Well..... i didn't 'put' the read-only bit there.... and it was still downloading... makes me wonder ;-)

[guest69]

Hi,

Well, same problem here. Happened with the beta about a week old and with the just downloaded 1.4 (final) version. Here is the story:

I started a download with Bitcomet 0.60. Bitcomet works great, but with some torrents with a large (over 1,000) peers, it often makes my CPU usage WAY too high, causing problems. It's some sort of bug with the BC 0.60. This download was particularly large, about 10GB with 2MB chunks spread into about 20 files. I downloaded about 10% with bitcomet and grew tire of the CPU usage problem, so tried uTorrent for the first time. Renamed the .bc! files, pointed to the right places, and off we go. For the next 1 1/2 days everything worked fine and utorrent took my torrent from 10 to >30% quickly and efficiently. I noticed less sources that Bitcomet 0.60 was finding, about 800 as oppossed to BC >1,500, but no problem there.

Then, out of the blue, the "cannot access" error came up and the torrent stopped. Restarting the torrent only worked for a few minutes at best. Searched for the problems on forums and tried all possibilities. So here it goes:

-First and foremost: the obvious. I checked the FAQ, searched the forum, this is the only torrent being downloaded, this is the only instance of utorrent, i tried with certain files "checked" (being selectively downloaded) and with all of them (the whole say 20 files), I rebooted, I'm a computer expert, etc

For all the tests I did below, I want everyone to remember that the torrent was working fine for about 1 1/2 days without anything being changed meanwhile and during that time some 2+GB was downloaded. As soon as the "access denied" problem started happening, nothing I tried could get the torrent to resume for more than a few minutes at best.

This is windows xp pro, US edition, updated to the latest of the latest Remember again, the download worked fine from the time i installed utorrent without interruption for the next few days and several hundred MB until it gave the error for the first time and ever since.

-I do run Norton Antivirus 2005 and nothing else. I deactivated it. It doesn't automatically update, so it was the same it's been for the past 5/6 days. I doubt it's the problem. If it helps, only recent "weird" update was the update to the December version of DirectX 9 from Microsoft some days ago.

-I did set the flags on the files. Manually with command line, through windows, to +A and to +AS, installed some unlock utility, etc, etc. Tried everything: renaming files, erasing .torrent and re-downloading, rechecking (re-hashing), sharing on network (I don't have a network, but just in case), you name it. Nothing seems to get utorrent to stop the error.

-I have always had all windows media explorer extensions deactivated. Regardless, I tried rebooting and just running utorrent w/o ever opening the explorer.

-I tried the latest (just downloaded) 1.4 version of utorrent. If anything, it seems to be worse at this problem.

-Tried disabling that cache option in utorrent (u know which one). Because I resumed the download with bitcomet I no longer want to run utorrent to avoid conflicts, so I'm talking from memory and being a utorrent user for only a short day or two don't remember exactly the name of all the options etc.

Long story short: I can not figure out where the error comes from. My opinion: write a better error desciption that "access denied" ... something like the name of the file being tried to write to or something would help.

Regardless, my opinion is that it's a bug NOT related to the file access rights, at least not the files being downloaded, since it seems to happen also while forced-REHASING the torrent. In another words, seems to be some sort of lock that is left somewhere RELATED to the files downloaded but not the files themselves, I don't think. Where does utorrent store the information related to a .torrent? (u know, percentages, chunks downloaded, etc)

Or perhaps just some sort of hash check that, when failed or whatever, erroneusly reports the error as "access denied" when it's something "else".

Whenever it gets fixed, I hope to use utorrent again as it seems second best to Bitcomet, which I would never leave if it weren't for the cpu-usage bug with large torrents. I switched the same torrent (back) to bitcomet 0.60, renaming the files with .bc! at the end, and bitcomet resumed without problems and got me another 2% more done in the past few hours.

Let me know if there is any information more especific that could help track this bug as I think it's a real problem and (not only) related to external software trying to access the file while uT wants exclusive access and locks fails or whatever.

Forgot to mention that last tests gave this conclusion: with the prior Beta, when torrent was forced to manually rehash or re-started after that and tried to rehash by itself, it always stopped at the same (around 30%) point. So it no longer could download even for a few minutes. And with the new 1.4 version, as soon as it starts to rehash, it also shown the error. Even after a clean boot, etc. As i said, I would look into some hash check routine problem ending in the wrong "cannot access" error code. But also remember that before rehashing was forced (or became necessary to start the download), the torrent started to download fine and at some point on the download (a few minutes, a few MB's) it would fail with the error also.

If it helps, the torrent includes some zero length files (i.e. "\AUDIO_TS" empty directory by itself).

[guest69]

Just for further information, I have of course disabled (long ago) indexing and the like. Also decided to try utorrent again after downloading for a while with Bitcomet. Well, same problem. At about 35% of the rehash, always same point, it gives me the access error. I tried re-downloading the .torrent file, pointing to different directories, selecting different files, etc. Always the error, on the same spot.

So i decided to try once more but "erasing" some of the already partially downloaded files. Well, I isolated a small group of partially downloaded files that, if present, will give the access error. Didn't bother pinpointing one in particular, as they were 4 o 5 small inconsecuential files (3x5kb .jpg, one .htm and one .txt of less than 1k or maybe even 0bytes).

I can not figure anything wrong with those files (attributes, locks, access, etc), so I once again think that a hash-check error has gone bersek and ends up being reported as an "access error" and makes the torrent stop rather than re-download or whatever. If it helps, one of the files has Asian characters in the file name (I ran imei) and has a 0 length although it occupies 1 block. Whatever, there is a bug somewhere with the hash-check-file-write that gives inappropiate cannot access errors. If the error gets logged to a window, I could gladly try to reproduce it and find out more information. Also a ~uTorrentPartFile_2A694AAFC.dat appeared in the (temporary) download directory from i don't know where.

So anyway, let me know if anyone needs more info to find this bug. But it looks to me that it's a bug, and not an external software interference.

[Firon]

Hmm... no idea what could be causing this. I'll point ludde to this thread.

[guest69]

Hmmm ... just noticed from switching back and forth between Bitcomet and uTorrent that BC finds far more peers more than twice utorrents 400, and that download speeds are far faster (utorrent seems to limit too much based on upload).

Clients that limit their downloads too much based on uploads are it for me. I have 384/1Mbit. As you know, uploads are on 100% of the time, while downloads only go on while there is something to download and someone willing to send it. But we all appreciate watching that TV show today rather than tomorrow. Do NOT limit downloads too much, something like emule's 3x to 4x the upload is reasonable. Don't complain about leechers. There will always be leachers and they'll use whatever client or whatever mod. Do not punish normal users (70%) for leachers. Samething as copyprotection etc ... pirates are ALWAYS going to pirate and leachers are ALWAYS going to leach, copyprotection, caps, private shares and the like only end up punishing regulars users that "pay" for other's sins.

Back to Bitcomet Hope they fix that CPU bug and come one with a 0.61, but I'm not holding my breath. It's annoying, but can be lived with. Or hope the uTorrent guys relax the download cap and are a tad more aggressive finding sources and making connections.

[Firon]

µTorrent doesn't cap the download for any upload caps except 1-5 KiB/s

[guest69]

That sounds good ... is that 1-5KB/ or Kb/s? And is that per torrent, global or per uploading task? I'm giving uT a try again, and my upload is 30KB with 4 preferred uploads at a time and only 1 Torrent. So far it's doing reasonably well with download speed again (compared to BC doing the same torrent which still was faster, but no longer by much) but indeed ut finds about half the number of peers (DHT was active in both uT and BC, this torrent seems to use several trackers, hope uT checks them all).

[Firon]

1-5 kilobytes (kibibytes)

It's the global upload cap only. For your upload, you should cap it to a reasonable amount (22-23 is a good value to start with). Feel free to adjust your # of connections to find a good amount too.

And finding a ton of peers doesn't really matter once you reach a certain amount.

µT has a less abusive multi-tracker implementation than BC (and yes BC's is abusive, as well as that ignoring the update interval specified by the tracker), it checks all tiers, but only one tracker per tier on each announce interval. You can see which ones are in a different tier by seeing which ones have an empty newline between them.

And uh, I guess it's because of a lack of peer exchange that explains why BC gets more peers.

[serlex]

Im also suffering from that bug. Actually I get the message

"Procees cant have access to the files because they are being used by anoher process"

I have tried mostly everything, just like lguest69, but no luck at all...

[Firon]

http://www.utorrent.com/faq.php#I_get_Error_Access_Denied_and_.C2.B5Torrent_halts_the_torrent

Nothing there helps I guess? :/

[Alphonse]

FWIW, I have exactly the same problem: all torrents are fine except for two, of which one is permanently stuck at 49%, whenever I try restarting it, it stops again with the "Access is denied" message.

AV scanning and Indexing Service disabled; Readonly attribute not set on any of the files. diskio.flush_files set to false. Help!

[Firon]

Try Unlocker to see wht's locking the file.

[eNuffSaid]

I'm having a similar problem. I've uploaded a torrent (approx 800MB), but everybody's stuck at 99.4%. I've restarted my client, my PC, but no help. There are no new files / thumbnails. I've removed the read only attributes (i'm only seeding this torrent, never downloaded), but still nobody is getting the last 0.6%.

I've put it in the super seed mode, but nothing happens. I don't get any error messages, and the torrent doesn't stop or anything.

Any tips?

Thanks very much,

'nuff

EDIT:

I think I've found the problem for me. I had some files double in my upload folder, but with 0k size. These files (my original ones) had some strange characters in the file name, like the upside down question mark and the capital A with accents on it. Somehow duplicate files were created with an almost similar name, but with the special characters doubled. I deleted those files, but now my upload shows as incomplete because the tracker thinks they were part of the original upload. How can I fix this?

[eNuffSaid]

Guys 'n gals,

I removed the strange characters and re-did the torrent from scratch. I asked the downloaders to download the new torrent and AGAIN they're stuck, now at 97%. This is getting anoying. I too am starting to wonder if there's something wrong with uTorrent.

Otherwise I find this an EXCELLENT torrent client.

Thanks,

'nuff

[Firon]

So what exactly is the problem right now, you get access denied or what?