BitComet Folder is "Read only"

[kusamba]

OK, I have read similar postings, faq and the like. English is my native language. My problem is that when I close BitComet and then reopen it, my current download tasks are gone. What is in the list are two old downloads. The file downloads.xml is dated 08/03/2009. I have used BitComet several times since that date and have also upgraded to 1.15. This file has full "allow" permissions for all users. There is also a file named downloads.xml.temp that is dated 11/08/2009.

Based upon what I read in response to other similar problem posts (once past the sarcasm), I checked to see if the BitComet folder was read only. ALL folders in the "program files" directory are Read Only. I tried to "uncheck" "Read Only" and it takes it OK, but when you hit "Apply" or "OK", I get a message "Do you want to apply this change to the folder only, or do you want to apply it to all subfolders and files as well?". "Apply changes to this folder only" is grayed out. The "Apply changes to this folder, subfolder and files." radio button is checked. I hit "OK" and it returns to the BitComet folder properties window. "Read Only" is "unchecked" - that seems good. I hit "OK". All appears fine. However, the BitComet folder is still read only and my problem with BitComet remains.

I am running BitComet 1.15, Vista Home Premium SP2 64bit and using AVG 9.0 No firewall. My connection is through a cellular modem - 3g with speeds shown by SpeakEasy to be 1500 kbps download and 350 kbps upload.

A second issue since I have your ear.... I downloaded a 72 meg file very quickly at full speed. At the same time I am downloading a large game file of 3.8 gig. The large file speed never exceeds 500 kbps. The smaller files are 1000-1200 kbps. All large files I download are relatively slow as this example. It happens day or night, any day of the week. Is there a tweak with which I am unfamiliar?

Thanks in advnace for your help. k

Edited November 9, 2009 by cassie
Changed to an easier-to-read font style (see edit history)

[kluelos]

Did you try changing the settings on the individual files themselves? They, too, and not just the folder they are in, must be writable by the account that BitComet runs under.

The download speed of a torrent depends on the composition of the swarm, which means that every torrent will differ from every other. Some have enough members in the right locations to max out your connection. Some do not. This is the single largest determinant of how fast your download will be, and there is nothing at all that you can do about it. Once you've assured that your client is properly configured, you are at the mercy of circumstance.

[kusamba]

Thanks for your prompt response.

Yes, my first step was to check the permissions on the downloads.xml file - all permissions were set to "allow".

I have read throughout this forum and find nowhere where anyone actually has fixed this problem. Is there a solution? Is this a bug in the newer 2 versions of BitComet?

I understand your explanation of the speed factor - thanks

Please use the "Fast Reply" option, unless there is a specific reason for quoting the post directlly prior to your own.

Edited November 9, 2009 by cassie (see edit history)

[kluelos]

It's an operating system issue, and doesn't actually have anything to do with BitComet itself. When Vista came out we were plagued with these issues, and yes, many people have solved their problems this way.

One of the biggest issues is "virtual storage", which means that the program directory isn't the program directory anymore -- it's somewhere else. What Vista says is "Program Files" is off somewhere under the Documents and Settings folder. Meantime the real Program Files directory is still there. You need to make sure you're adjusting the permissions for the right one, which in practice means doing it for both.

You also need to make sure that the permissions you're granting definitely do apply to the account that BitComet runs as. Lots of people make changes for the Administrator account but forget that BitComet doesn't run as an administrator. (It certainly shouldn't.)

[kusamba]

I searched my hard drive for all instances of "downloads.xml" using "Include non-indexed, hidden, and system files". It found only one instance and the permissions on this file are all "allow". However, as before, this file has not been updated - it does not contain current data and the file date has not been updated. "downloads.xml.temp" is present in the same folder, has been updated with current data by BitComet, and has today's date and time.

I have no idea how to fix this. I asked a couple of system engineers at work to look at it and they have no clue. One of them uses BitComet and has had the same problem for the same time period as I.

[kluelos]

Exit BitComet, then try copying the file that you've found, and pasting it into the correct Virtual Storage folder. Them delete the ".temp" appendage, so that the file now has the correct name. Then restart BitComet and see if your task list now reflects the content of that file.

If it already is in the proper folder, then just delete the existing .xml and rename the .xml.temp file. It may be that BitComet cannot, for some other reason, remove or rewrite that existing file.

This is sort of crude and backwards, like push-starting a car with a manual transmission, but it may work.

[kusamba]

Well it did work! Thanks a bunch. Now we'll see if it keeps updating this file from day to day. :)

2nd petition - Please use the "Fast Reply" option, unless there is a specific reason for quoting the post directlly prior to your own.

Edited November 10, 2009 by cassie (see edit history)

[greywizard]

You can check that right away. All you need to do, is exit BitComet and start it again.

Just out of curiosity, what was the folder where you found the 2 files?

Was it %systemroot%:\Program Files\BitComet or it was the %systemroot%\Users\%userprofile%\AppData\Local\VirtualStore\Program Files\BitComet folder? But you'd have to manually navigate towards both locations to check that, since I think Vista might present aggregate views of both folders to the search function.

Also, just to make sure: Did you check before, the folder's permissions, too? Because if they aren't enabled, it wouldn't work just the same.

[kusamba]

I did exit BitComet and start it again. That's how I determined that your solution worked. I just wasn't sure that it would work every day. Since I do not know how it went astray in August, I am not sure how this solution fixed it. (but it did)

I found the files in %systemroot%\Users\%userprofile%\AppData\Local\VirtualStore\Program Files\BitComet. The attributes for this folder show "Read Only". I am unable to change that.

Again, I appreciate your help in resolving this. Seems strange that so many people posted the same problem. Hopefully they can take advantage of this solution as well.

And sorry to "Cassie" about "quoting" the previous post. B)

[greywizard]

I was not talking about the folder's attributes but about its permissions which are an entirely different thing.

Those should be altered (granted full access) under an administrator account, for the account BitComet is running currently under, and you might need to first take ownership of the folder, it that doesn't work at the first attempt.

And BC should be closed when all this is attempted.

[kusamba]

Well, the problem still exists. I have attached screen prints for the BitComet Folder Permissions, the file downloads.xml permissions, and for the BitComet Folder contents. You can see that the downloads.xml file still has the date of 9 Nov yet the temp file is dated today, 13 Nov correctly. BitComet has been opened and closed several times since the 9th. The contents of the former are old/wrong. The contents of downloads.xml.temp are current and should be written to downloads.xml when BitComet is closed. This file is not getting written and there is no error message.

After you had me create a new downloads.xml file from its temp file, when I opened BitComet, it seemed to be working. However, I noticed that the percent complete was wrong. It seemed to scan the file and then reset the percent complete and then continue working properly. I assume now that the downloads.xk file has never been written correctly since 3 Aug.

The permissions are the same for all 3 "users" - SYSTEM, dac, and Administrators.

I am upgrading to 1.16 tonight - maybe that will help.

[kluelos]

When you log on, which account do you use?

[greywizard]

I believe it's a Windows related issue, too.

Just to check the facts: is your downloads.xml writable (not read-only), now?

Furthermore, could you check that your account has ownership of the BitComet folder (make sure that under Current owner is your account mentioned and check the Replace owner on subcontainers and objects)?

If both the above things are already in place then try this:

Open a new Notepad document.

Copy-paste the text below:

%homedrive%
cd \
cd %localappdata%\virtualstore\program files\bitcomet
echo Hello > Downloads.xml

Choose the

All files

file type and save the file under a name like

test.bat

. Run the .bat file.

It should overwrite the contents of your actual Downloads.xml with the word "Hello".

After that open the .xml file; if the contents are unchanged it means that Windows is preventing you (and BitComet) from writing in the folder.

[kusamba]

I log on to the "dac" account as a normal user.

[kusamba]

I just closed BitComet and it wrote a new downloads.xml file. I have no idea why - I did not change anything in terms of permissions, etc. I did upgrade to 1.16 yesterday though.