I have a roaming profile with a size limit of 150 MB in Windows XP
CHC files are automatically downloaded to the application data folder in this profile
I have to remove the chc files to another location
Can somebody explain how I can inform FlashBuilder the new location of the CHC files.
AND - even better - how to arrange that the CHC files are downloaded to a location of my choice instead of to the application data folder?.
Currently I cannot get any help any more in any of the adobe applications.
Clearly this has to do with the fact that I have to move downloads from my roaming profile to another location.
It would be helpful if I could at least get help on reinstalling help in such a way that it does not download into my roaming profile.
Note that I am working in a trial version in order to decide if we should invest Flash/Flex productions....
Did you manage to sort your problem out with the chc files?
I've just discovered a similar issue. We run a domain with roaming profiles, and it seems that CS5 stores cached adobe community help files into the directory "AppData\Roaming\chc.'random salted characters'\Local Sore\Help\"
eg: "AppData\Roaming\chc.4875E02D9FB21DD389F73B8D3802B320485DF8CE.1\Local Sore\Help\
This is currently over 380MB, which makes logon times longer than necessary.
If you use group policy management there is a User Policy "exclude directories from roaming profile" that can stop certain directories from being synced to the domain controller, however this policy won't accept wildcards (*) for specifying all occurrences of chc*. So you have to put the whole path in for each user!
You can't even block a parent directory instead, as this chc directory is in the root of the Roaming profile folder. Unless I'm missing something obvious here it seems like a bit of a pain of a design choice.
Mozilla thunderbird also has salted directories for it's user profiles, but at least they're within a subdirectory that can itself be excluded. We're lucky in this case that I only have one user with CS5 installed so its ok to block just that single salted directory, but I do wonder what companies with many copies do?
Alas, we have not been successful in finding a solution or work around I was working with the trial version. The idea was to make people enthousiast. But this problem currently has the opposite effect.....
Alas, we have not been successful in finding a solution or work around
I was working with the trial version.
The idea was to make people enthousiast.
But this problem currently has the opposite effect.....
Hi all: I am the product manager the Community Help app and this is a known issue. We will address this in an upcoming release just as soon as we can. I apologize for the inconvenience and we understand that this is a serious problem for users with roaming profiles.
In the meanwhile, if you have additional questions or feature requests specific to the Community Help application, I encourage you to share them in our dedicated forum over here:
Any idea how long it will be before this is fixed? We use Creative Suite 5 in our corporate environment with roaming profiles. The problem is not just that the help files go in the roaming part of the users profile but that they take forever to sync as part of the roaming profile update.
I have profiles that are 10gb that only take a few seconds to login and log out because the roaming profile only updates what has been changed. The CHC files however have to update the entire 380mb of data each time the user logs in and logs out. What is causing these files to be changed? I remove the CHC files from the profile and even the 10gb profile updates in seconds, with the CHC files in any size profile the 380mb takes 3-4 minutes to update on either login or logout.
You can get around this by GPO to exclude or filter the CHC folder out or you can update the nsuser.ini file to exclude this folder. On a large network this is a pain and it surprises me that the CS5 product is made for large enterprises that a fix isn't out yet.
Any progress on this issue? It's been about 6 months since the original post. I've just discovered a wad of about 300Mb of help cache files in my roaming profile, and I'd like to tell all my Adobe products to store such things in a more sane place.
Hi: I apologize for the lack of information on this particular topic. The Help engineering team has proposed some potential alternatives to this issue but all of the changes require substantial changes to the product installer -- which in turn, require development and resources on the product team. Unfortunately, that level of change is out of scope for the short term but we are lobbying hard to get the various teams to buy in for the next major release.
We're doing the best we can -- and we have not forgotten about this request. It remains a priority issue for the Help team.
As I mentioned back up a few posts and smithje30 mentioned above, you can filter the directory with GPO, but the main problem with this method is that the chc.'random-salt" directory is in the AppData\Roaming root and so you have to do it manually for each user (different random salt each time).
If you could just place the chc one subdirectory down eg: AppData\Roaming\AdobeCHC\chc.'random-salt" then I can block AppData\Roaming\AdobeCHC\ from roaming for all users and be much happier.
Pretty please move it one directory down?
In the meantime, perhaps a workaround would be to empty the chc.xx directory, and then make it write-protected? Would the software gracefully fail over to just re-downloading help info from the net each time, or would this break something?
Another alternative would be to use an NTFS junction to redirect the folder somewhere else. To be honest, I'm not sure I see the reason to cache help info anywhere but Temp... I mean, how many times are you going to search for help on the same topic?
Another alternative would be to use an NTFS junction to redirect the folder somewhere else...
That's an interesting idea, I'm not very familiar with junctions, I'll have to give it a go and see what happens.
Would the login process not follow the junction similar to some unix systems following symlinks and just then sync from the alternative physical location.
Dear Adobe / Mark Nochoson -- thanks for your attention. It's somewhat rude and alarming to spew data without at least putting your name on it clearly.I was worried some malware had slipped through before I got a look at the contents of the log/installer files.
I have no idea why this couldn't be a subfolder in the AppData\Roaming\Adobe folder or why it's not called com.adobe.CommunityHelp.12345678.... following the example of the mildly annoying but at least recognizable com.adobe.AdobeStory, com.adobe.DC3Module, and com.adobe.downloadassistant.(Are these goups trying to pretend this is a Mac or something? Smells catty to me. Just stick everything in the Adobe folder and use your silly folder names from there, okay?)
For me the problem is that I'm using a small mini-PCI/e SDD to boot my notebook; big files/folders I relocate to its HDD using junctions. Junctions are a long-standing feature of NTFS that's pretty much been ignored by Windows Explorer. Possibly wisely so for the sanity of most users and the techs who support them.
There's a wonderful, free utility that lets you create and manipulate junctions, hardlinks, and symbolic links by right-clicking: http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html You should actually read that page, particularly about the "Smart Move" feature which I found I needed to disable and continuing down to the "Backgrounders" section that explains the differences between Hardlinks, Junctions, and Symbolic Links. Some aspects are pretty subtle. But if you don't go crazy with links to links and can avoid moving things around once you've relocated them, you should be fine.