unfortunally, my old forum user account seems to be lost, so I cannot refer to previous posts...
Here is a similar issue to that what I've mentioned earlier.
Within a domain and terminalserver environment with roaming profiles, often the profile space is greatly limited to a few megabytes. So it's not a good idea to keep the VOS cache there. Sure, there is a feature called folder redirection, but for whatever reason the admin don't implement that, %appdata% resides within the local, limited profile.
The other location, where the user (and only the user) has guaranteed write access, is the homedrive, which is in such environments typically not part of the profile, but a separatly drive/path with no such strict size limits.
The only way I can think of using this space now, is leaving the default VOS-space and setting CAMEYO_BASEDIRNAME to %home% (or whatever is suitable), but this has to be done each time before the user calls the app, since it's to great an effort to set this envvar on each and every machine the user possibly calls the app...
So, I think, the available "Path variables" should be extended to at least a var names %Home% or so.
And another suggestion: why not allow arbitrary Environment-Variables at this location? If they point to a writable dir, this would be far better then hard coding a path like U:\...
Maybe another solution is available, but since I cannot find the old posts, I cannot remember...
I just realized that setting CAMEYO_BASEDIR to an mapped network drive does not function. So I have no way right now to redirect VOS to a position outside the profile. Even %temp% is not available (%temp% is not taken into account when measuring the profile space).
- When you say the base dir does not work if you use a mapped drive, what version are you using? There have been issues fixed in this regard in Cameyo 2.0 (including general mapped drives, and DFS mapped drives).
- When you say it is too much work to set the CAMEYO_BASEDIRNAME on every machine before launching a virtual application, why not just modify this in the app itself, using the Package Editor?
- When you say the Path variables should be extended to a var name "%Home%", are you referring to "%Home%" specifically, or to supporting Windows variable in general?
- Up until now, I'm using v1.7 (started 2.0 a few times, and ad no time to inspect the new interface...) - How do I set this var from within the package editor? That´s one thing I don't understand. Probably you mailed me a solution times ago, but unfortunally I can't find it... Additionally I thougt, this var must be present when the app launches... - Unfortunally, API functions like WshSpecialFolders don't return information about the location auf the homedrive in a domain environment. The only way to determine I know about is described here: http://support.microsoft.com/kb/101507/en-us. But to avoid to handle the severals vars, I think it would be great if two abstract (synthetic) variables would be defined by cameyo, like HomeDir and HomeDirUNC (which contain something like H:\ or \\server\home\username). - Additionally, it would be great if not only the special cameyo-%vars%, but the standard systemvars where available, too. So, yes, i meant system vars in general. Perhaps in the notation %%var%% to not get confused with the cameyo vars.
How do you set the path from the Package Editor? Just open the app in the Package Editor, and set the "Data storage" to "Custom location". Put there whatever you want; a variable will not be necessary then.
Regarding variables, your idea of defining Windows environment variabels with "%%" is good. It'll be available in the next 2.0 build (build 812 or higher).
Actually, once this is done - why do you then need a synthetic variable "%HomeDir%" and "%HomeDirUNC%"? Why not just use "%%HOMEDRIVE%%%%HOMEPATH%%" or "%%HOMESHARE%%" ?
'set the "Data storage" to "Custom location". Put there whatever you want; a variable will not be necessary then.' -> yes that's clear, but using constants there is not a good idea. In out environment, the home drive is u:, OR sometimes n: OR sometimes elsewhere. So a package with a constant is not system independent. So using a var there is required.
1) Ah, okay, I don't know that the use of env vars is possible there, too. Thanks.
2) The only reason is that sometimes exists the need to differentiate between situations, where the homepath is at root level or not, so it's not always correct to simply concatenate %HomeDrive%%HomePath% with another path element (thanks Microsoft!).
Sometimes, Double-Backslashes in path specs are ignored, sometimes not. It's better to have a logic to handle this, which is impossible in a simple entry field...
As far as I can see, double backslash is supported on all operating systems XP and higher. Do you see something different? If so, can you provide some reference / way to reproduce?
Changed to the newest engine. Error message still is "failed deploying files"... (with VOS custum loc %%HomeDrive%%%%HomePath%%, while the current value is:
>echo %HomeDrive%%HomePath% C:\Dokumente und Einstellungen\Arbeit1
Maybe some "blank" Problem?
-- Edited by MHo on Thursday 9th of August 2012 02:58:48 PM
Is there a way, to distinguish, regarding cached data, between machine dependant and user dependant data? I have to fight against space restrictions. If I set the location of VOS, e.g., to %Internet Temp%, then everything runs fine, until the user logs off. Next logon, her settings are lost, as %Internet Temp% isn't subject of roaming (good reasons for that), that's why this folder don't count for the profile space limit. And the user storage also resided within VOS.
I would prefer: I can define, where programs and dlls get cached, and I can define, where userdata is cached, separately.
I just tested %%HomeDrive%%%%HomePath%% for custom location and got a 26 error.
I'm very sorry, I just realized (with -enginever) that the engine of the package adressed above is not at the newest level.... I thought that opening end editing and saving an existing package would provide it with the newest engine, which was not the case... So, I'll better test -changeEngine first...
Hm.... Don't know what's different now, but just tested with another paket again the custom location for VOS (%%homedrive%%%%homepath%%), and everything works as expected....
Oh, a never ending story. If, for example, I modify the filezilla package, I had to do the following:
- Clear the VOS/Cameyo cache - Run Cameyo -> the newest Loader and AppVirtl.dll are then there - run filezilla -changeLoader - run filezilla -changeEngine - modify to custom location %%HomeDrive%%%%HomePath%% ---> The app starts now, but gives the following error: "Cannot load quick connect bar..." and later crashes. - changing back to Standardlocation (Caching in %AppData%) doesn't help then... - I had to download the original filezilla from here...
If you repackage Filezilla (instead of using ChangeLoader & ChangeEngine), does it help? Also, what are the values of your HOMEDRIVE and HOMEPATH variables? (please include training \ etc)
Unfortunally, I didn't had the time to re-package FileZilla yet, so I switches to using a portable version....
The values auf %%HomeDrive%%%%HomePath%% where U: and \, so U:\ was the path (a network drive). Seems that FileZilla wasn't able to load resources then.... hm.... very strange.
