"Store settings per user account" works incorrect

[Dm1 0]

Maybe someone already posted about this issue, but searching gives nothing.

New feature in ApexDC++ 1.3.1, "Store settings per user account" seems to be buggy on Windows 7. When I am using ApexDC, installed with this option disabled - everything works OK. But if I will enable it (it was added specially for Vista/7, so must be enabled on them, I thought) and will try to download something - I will get endless loop of downloading this file with "TTH:" prefix in the filename many times per second. It looks like file download finishes immediately, then starts again... and again... endless:

And nothing appears in file destination and even temporary folder. I decided that this is wrong NTFS access permissions somewhere, but I didn't changed them (except adding for "ApexDC++" directory in Program Files full access for my user account to work without that feature in earlier versions) , so they are in there default values, so it looks like ApexDC is doing something wrong. Thanks. :)

[Crise 26]

Maybe someone already posted about this issue, but searching gives nothing.

New feature in ApexDC++ 1.3.1, "Store settings per user account" seems to be buggy on Windows 7. When I am using ApexDC, installed with this option disabled - everything works OK. But if I will enable it (it was added specially for Vista/7, so must be enabled on them, I thought) and will try to download something - I will get endless loop of downloading this file with "TTH:" prefix in the filename many times per second. It looks like file download finishes immediately, then starts again... and again... endless:

And nothing appears in file destination and even temporary folder. I decided that this is wrong NTFS access permissions somewhere, but I didn't changed them (except adding for "ApexDC++" directory in Program Files full access for my user account to work without that feature in earlier versions) , so they are in there default values, so it looks like ApexDC is doing something wrong. Thanks.

Hmm, what are your downloads and temporary directories set to, in settings?

[Dm1 0]

I am using "E:\Temp\" as temporary folder. It's on a big partition on which I store all my downloads and share.

I have got more information to think about. I can still download file-lists with this "Store settings per user account" option enabled and even some files, looks like which are smaller than some specific size value. Can't download typical 10 MB mp3's, but can some txt's, which are ~200KB. I think it happens because the temporary folder is not used for them? But how can settings, stored in user folder, deny access to temporary folder on the other drive?

[Crise 26]

I am using "E:\Temp\" as temporary folder. It's on a big partition on which I store all my downloads and share.

I have got more information to think about. I can still download file-lists with this "Store settings per user account" option enabled and even some files, looks like which are smaller than some specific size value. Can't download typical 10 MB mp3's, but can some txt's, which are ~200KB. I think it happens because the temporary folder is not used for them? But how can settings, stored in user folder, deny access to temporary folder on the other drive?

That shouldn't be possible... actually assuming all files get saved where they are supposed to be saved there shouldn't be any permission issues.

Can you check your AppData and tell what files are in each of the "ApexDC++" directories.. just to see if everything gets created/moved correctly.

Edit: I assume your finished downloads directory also exists and is "writeable"

[Dm1 0]

%USERPROFILE%\AppData\Local\ApexDC++\

FileLists\VariV.YUJQO5DMLVDEBR7PEBSEBTJ6OJA4M5IJTUUIMJA.xml.bz2

HubLists\http___dchublist.com_hublist.xml.bz2

Plugins.xml

%USERPROFILE%\AppData\Roaming\ApexDC++\

ADLSearch.xml

DCPlusPlus.xml

Emptyfiles.xml.bz2

Favorites.xml

files.xml.bz2

HashData.dat

HashIndex.xml

Profiles.xml

Queue.xml

Queue.xml.bak

Raws.xml

Recents.xml

"%PROGRAMDATA%" has no ApexDC++ directory. Sure, because it stores for all users, like in older Windows versions was directly in "Program Files". So I think with "Store settings per user account" option disabled, ApexDC++ better to use it, than write protected for non admin users "Program Files" on Windows 7. It is just simply wish for better compability of future OS's and irrelevant to this topic.

Also my ApexDC++ is not clearly installed with this option, it was upgraded by installing new version with this new feature enabled in the previous version of ApexDC++ directory. Maybe it causes the problem? Some issues with moving settings location when upgrading and clear install will fix that? But even in that case, it requires correction. Thanks for trying to help me

Edit: I assume your finished downloads directory also exists and is "writeable"

Yes of course, without "per user" option I can download everything to the same directory, which I can't use when it's enabled.

[Crise 26]

About ProgramData... that is for visualization (ie. what windows uses for legacy apps that don't have the UAC awareness indicated by manifest). While I suppose it would be possible to force an UAC aware app like ApexDC to use that directory but really I don't think any apps should write files in there directly.

What windows does is use that folder to write the files when an old application (that isn't UAC aware so to speak) tries to write to say Program Files directory.

After looking at that list of files all I can say is that the files themselves have been moved correctly (well they might also have been recreated, but then you could probably tell since some of your settings would likely have been lost, like sy the hash data.)

[Dm1 0]

About ProgramData... that is for visualization (ie. what windows uses for legacy apps that don't have the UAC awareness indicated by manifest). While I suppose it would be possible to force an UAC aware app like ApexDC to use that directory but really I don't think any apps should write files in there directly.

What windows does is use that folder to write the files when an old application (that isn't UAC aware so to speak) tries to write to say Program Files directory...

Directory what are talking about is "%USERPROFILE%\AppData\Local\VirtualStore\Program Files\", but "%SYSTEMDRIVE%\ProgramData\" is application data storage for all users accounts. I don't want to argue about this now, because it's not causing any serious problems for users, they just need to add access permissions for the ApexDC++ folder and everything will work fine even in old way.

...

After looking at that list of files all I can say is that the files themselves have been moved correctly (well they might also have been recreated, but then you could probably tell since some of your settings would likely have been lost, like sy the hash data.)

OK, maybe I can find the source of the problem myself. But I need some information. Why ApexDC adds "TTH:" prefix to the filename when this problem happens? What does it mean?

[Crise 26]

Directory what are talking about is "%USERPROFILE%\AppData\Local\VirtualStore\Program Files\", but "%SYSTEMDRIVE%\ProgramData\" is application data storage for all users accounts. I don't want to argue about this now, because it's not causing any serious problems for users, they just need to add access permissions for the ApexDC++ folder and everything will work fine even in old way.

Sorry my mistake... I should have checked my facts, I completely forgot about the VirtualStore in AppData.

OK, maybe I can find the source of the problem myself. But I need some information. Why ApexDC adds "TTH:" prefix to the filename when this problem happens? What does it mean?

When Apex does this it is requesting the TTH tree for the file/chunk (the blinking that you describe is probably caused by not being able to write that data into a file), the problem in question is pretty common when Apex is in local mode and can't write to the "Settings" directory.

[Dm1 0]

Problem is solved. When updating Apex to 1.3.1 with storing settings per user account, installer moves files, listed above, with ignoring their current permissions (who knows, users could run Apex always as administrator before). It has no troubles with it, because it has administrative rights. But Apex then runs with user privileges, and we can get a problem sometimes. In my example there was two files which has unheritable read only permissions for users: ADLSearch.xml and HashData.dat. All other files and the folder has them correct. I don't know why this files could get such a strange permissions, maybe it is my fault, but before in program files all was correct and workable. I think something wrong with inheriting permissions could cause it will work in one folder, and failed to in another. Maybe Apex installer better to force reset access permissions of this files when moving them? :stuart:

[Zlobomir 3]

That's why I (we?) recommend disabling UAC, since UAC is quite easier to be tricked by malware rather than by a legitimate application. Or simply install Apex in say C:\ApexDC, where UAC does not have control.