Dm1

Sorry, my mistake, next time I will search better for already known bugs ^_^

Entering /ratio or /r command now crashes ApexDC++. Last time I used this command was on 1.2.2 version with no issues.

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:

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. 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?

%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 Yes of course, without "per user" option I can download everything to the same directory, which I can't use when it's enabled.

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?

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. :)

Thanks This reply I have expected from the beginning. Actually I am an OP on ISP hub already for ~5 years, and never saw any negative aspects of sharing unpacked images (that was not installed software above). Like I said before, no need to browse deep in this garbage, only download and launch. This is the first issue, and it just the result of usual bug in software developing process That was just a 1.7 update for the game, nothing more, I think :)

@Big Muscle. Are you an idiot? Whole file list is perfectly organized, and this example is only one path from it, which causing a problem. Have you ever used a Mac computer? Typical Mac users will download content of "\Install\Games\Call of Duty 4\Mac\". All that subdirectories is absolutely typical content of Mac OS X installers (which is not solid files, they are directories, hidden from users by the OS), they will never browse deep there. And update: ApexDC++ 1.3.0 file list is crashing on other users with long pathes, not only mine. Note: ApexDC++ is running on Windows XP, not Wine or something.

After adding the path shown below in ApexDC++ 1.3.0 share and then choosing "File -> Open own list", file list appears for a moment and then immidiately closes up. O_o If I'll make this path on one directory shorter - everything becomes OK, I can now browse my file list. All previous versions can handle first example without a problems. Fix this bug please, or probably add the attention message box when user tries to add too deep directory structure.

Thanks, now I remembered and & == & :D

Very necessary change And how we shall use symbols "&", "<", ">" in smiles now??? Unicode representation like "%3C" is not supported by ApexDC++.