This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Permit userdir to be split into preferences vs. cache | ||
---|---|---|---|
Product: | platform | Reporter: | ulfzibis <ulfzibis> |
Component: | Launchers&CLI | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, apireviews, dlipin, jchalupa, jglick, jtulach, kawkhins, mmirilovic, nigjo_iqn, pjiricka, vv159170 |
Priority: | P2 | Keywords: | API, API_REVIEW_FAST, PLAN |
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 201805, 201350 | ||
Bug Blocks: | 196075 | ||
Attachments: | Running patch ('hg pdi var_cache_57798' in core-main to refresh) |
Description
ulfzibis
2005-04-12 22:04:31 UTC
*** This issue has been marked as a duplicate of 49813 *** Move netbeans_default_userdir to APPDATA.
I reopen this issue, because the mentioned duplicate originally had a different
target and so has a misleading summary (no hint to the APPDATA part).
The userdir at Windows is not directly designated for application software usage.
I prefer (reasons see Issue 58381):
netbeans_default_userdir="${APPDATA}/Java/netbeans/4.1"
Note: JRE's settings folder is "${APPDATA}/Sun/Java/Deployment"
> jchalupa (Issue 49813):
> I tend to agree regarding the APPDATA part. Ideally, the application data should
> be stored in the 'Application Data' subfolder. The reason why NetBeans doesn't
> use it is that Java APIs don't provide a reliable way to get that folder. A
> possible workaround would be to use native code and Win32 APIs to get the name
> of the APPDATA folder. We can consider that for future releases.
For solution have a look at JRE's installer. ;-)
I don't see a precedent for *Java* in the suggested ${APPDATA}/Java/netbeans/4.1 folder name. IMO, the convention seems to be the vendor name under the ${APPDATA} folder. So, in the case of NetBeans, it would be: ${APPDATA}/NetBeans/4.1/ Anyway, this is not going to be implemented for 4.1. Too late. Isn't the vendor *Sun* ? No. NetBeans is an open source project, although Sun is the biggest contributor, of course. @jchalupa I agree with you. Thanks for discussion. I was thinking of Issue 58381 (All Java-apps in ../Java/..-path) when proposing the Java-part. So in following the convention, JRE should be in "Program Files\Sun\JRExx". I more like the convention proposed in Issue 58381: All Java apps in "Program Files\Java\...". So in following the convention, JRE should be in "Program Files\Sun\JRExx", but it is in "Program Files\Java\JRExx". IMO, the convention seems to be the "vendor name\product name" under the ${APPDATA} folder. So, in the case of NetBeans, it would be: ${APPDATA}/NetBeans/IDE/4.1/ Deplyoment in Sun's JDK uses http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetspecialfolderpath.asp with CSIDL_APPDATA param. Probably we can pass this information from launcher. Need to check what is the impact on settings import from earlier version. *** Issue 85229 has been marked as a duplicate of this issue. *** please also consider using c:\documents and settings\local settings\application data\Company\Product for settings that cannot be moved to another computer (from #85229) not the installer RFE but the platform`s one. There is a technical aspect to doing this change; Networked computers with "roaming profiles" a.k.a. Domain Computers. First, when you have roaming profiles the content of the user directory is copied into (or rather synchronized with) the server when you logout, one need not much of brainpower to realize that netbeans cache takes a long time to process causing long login/logout time. Second, the cache itself (rather the "var" directory) is local data belonging to the machine installation and thus should not be stored in the profile, some configuration settings however should be stored in the profile (like open projects that resides on networked drives or inside the profile itself) This means you cannot make the whole .netbeans directory local or roaming, it needs to be split into one part that is stored within the profile and one that is stored outside. Some say "this works on Linux", but then again, how many are there using windows contra Linux? (No I'm NOT going to respond to any l*x../..w*s comment's on this, so don't make any, this is a fact that should be known to everyone) Because of this I think this change should be made, not just for the current status but also for future changes to both l*x and w*s (In reply to comment #12) > There is a technical aspect to doing this change; Networked computers with > "roaming profiles" a.k.a. Domain Computers. You are right, thanks for that aspect. BTW: Mozilla Firefox has that splitting: Profile -> %APPDATA%\Mozilla\Firefox\... Cache -> %HOMEPATH%\Locale Settings\Application Data\Mozilla\Firefox\... Changing the summary to reflect the point made above. I guess on iX the two parts would be reasonable too, and on Windows in: Profile -> %APPDATA%\Netbeans\IDE xxx\... Cache/Var -> %HOMEPATH%\Locale Settings\Application Data\Netbeans\IDE xxx\... For the application I would prefer: %PogramFiles%\NetBeans\IDE xxx\ or %PogramFiles%\Oracle\NetBeans IDE xxx\ instead: %PogramFiles%\NetBeans xxx\ So there would only be 1 top folder for Netbeans in the PogramFiles tree, similar, as it is in the start menu tree. (In reply to comment #15) > I guess on iX the two parts would be reasonable too, and on Windows in: > Profile -> %APPDATA%\Netbeans\IDE xxx\... > Cache/Var -> %HOMEPATH%\Locale Settings\Application Data\Netbeans\IDE xxx\... > > For the application I would prefer: > %PogramFiles%\NetBeans\IDE xxx\ or %PogramFiles%\Oracle\NetBeans IDE xxx\ > instead: > %PogramFiles%\NetBeans xxx\ > > So there would only be 1 top folder for Netbeans in the PogramFiles tree, > similar, as it is in the start menu tree. I would prefer %ProgramFiles%\Netbeans IDE\%Version% i now have like 15 Netbeans folders ( nightly's and a few stables ) Also cache should be local only, settings i'm not sure if i want that romaing or not but it has to be put into %appdata%\Netbeans IDE\%Version% (In reply to comment #16) > I would prefer %ProgramFiles%\Netbeans IDE\%Version% The standard pattern on Windows is %ProgramFiles%\%Vendor%\%Product%\ I'm not sure about the right vendor of NetBeans (Oracle?). But keep in mind, there could be more products from NetBeans besides the IDE, e.g. NetBeans Platform. I'm 50/50 for both suggestions. > i now have like 15 Netbeans folders ( nightly's and a few stables ) Same to me, it's ugly! For the JDK part please comment on thread: http://mail.openjdk.java.net/pipermail/nio-discuss/2011-January/000501.html (In reply to comment #15) > I guess on iX the two parts would be reasonable too, and on Windows in: > Profile -> %APPDATA%\Netbeans\IDE xxx\... > Cache/Var -> %HOMEPATH%\Locale Settings\Application Data\Netbeans\IDE xxx\... Wherever the "cache" (or better "var") Directory will be, it will be a lot work to change the behavior of many modules. I did a quick search through the sources and many modules do similar things like this to get their "cache" folder: private File getStorageRootFile() { String userDir = System.getProperty("netbeans.user"); // NOI18N return new File(new File(userDir, "var"), "bugtracking"); // NOI18N } [NI01] I suggest a new system property value "netbeans.user.var" to point to the "local settings" and change all occurrences like the above to use this new one. As a fallback for installations which do not set "netbeans.user.var" in the launcher this property should be set somewhere early in the startup process. I've filed a bug: You can monitor this bug on the Java Bug Database at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7022730. It may take a day or two before your bug shows up in this external database. (In reply to comment #2) > Move netbeans_default_userdir to APPDATA. > > jchalupa (Issue 49813): > I tend to agree regarding the APPDATA part. Ideally, the application data should > be stored in the 'Application Data' subfolder. The reason why NetBeans doesn't > use it is that Java APIs don't provide a reliable way to get that folder. A > possible workaround would be to use native code and Win32 APIs to get the name > of the APPDATA folder. We can consider that for future releases. I found out, there is a way from the JRE: System.getEnv("APPDATA"); Leaving bug #196075 for the move of valuable files to APPDATA, this issue can be considered the problem of splitting var\ or var\cache\ to "Local Settings". Using var_cache_57798 pbranch in core-main. For simplicity, treating this issue just as the _capability_ of using a separate cache directory, with --cachedir to select one. API request for new org.openide.modules.Places. Bug #196075 should track changing the _default_ on Windows to use Application Data for the configuration part and Local Settings for the cache part; not sure if this can/should be done in the netbeans.exe launcher, or only in the installer. There may be appropriate defaults for other operating systems as well but I am not sure. Created attachment 109680 [details]
Running patch ('hg pdi var_cache_57798' in core-main to refresh)
(In reply to comment #23) > API request for new org.openide.modules.Places. It looks good to me on a first quick peek. > Bug #196075 should track changing the _default_ on > Windows to use Application Data for the configuration part and Local Settings > for the cache part; not sure if this can/should be done in the netbeans.exe > launcher, or only in the installer. There may be appropriate defaults for other > operating systems as well but I am not sure. The launcher can access the windows registry where all these paths are stored. This is already be done to get different folder locations. (via constant "REG_SHELL_FOLDERS_KEY") %APPDATA% key-entry is "AppData" you can use the key entry "Local AppData" for local settings. [NI02] In my current Win7 installation this comment is inside the registry key: "Use the SHGetFolderPath or SHGetKnownFolderPath function instead". SHGetKnownFolderPath (WinVista+): http://msdn.microsoft.com/en-us/library/bb762188%28v=vs.85%29.aspx SHGetFolderPath (WinXP and below): http://msdn.microsoft.com/en-us/library/bb762181%28v=vs.85%29.aspx [NI03] Shouldn't the whole "var" folder be moved to "local settings"? NI02 and related Windows-specific comments - thanks; please use bug #196075 for this though. NI03 - I think not. The great majority of the large files that would typically overload network drives, or be unwanted in a backup, are already in the cache/ subdir: parser indices, Maven repository indices, downloaded Auto Update catalogs, SVN offline caches, and so on. What remains in var/ is not that large on average and is typically not transparently recreated like a real cache would be: - log files (well you hope these do not get too large, anyway!) - attributes.xml (references to absolute file paths which might be shared across drives, and may include user preferences specific to files or to projects which decline to keep NB-specific metadata in versioned sources) - autoprojects.properties for http://wiki.netbeans.org/AutomaticProjects (currently a mix of cache and preferences, but generally small anyway) - filehistory (potentially valuable for backup; anyway some sort of history trimming probably needs to be introduced here, e.g. delete history prior to a SCM commit) - bugtracking (not clear to me if this is cache or not, but that is up to devs of that module to decide) - a few miscellaneous flag or lock files too small to bother with core-main #dc00bb155bce Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/dc00bb155bce User: Jesse Glick <jglick@netbeans.org> Log: #57798: permit var/cache/ to be stored separately from the userdir. I have a comment about change done in cnd.repository/src/org/netbeans/modules/cnd/repository/disk/StorageAllocator.java 97 prefix = reduceString(prefix); 98 -108 path = getCachePath() + File.separator + prefix + File.separator; // NOI18N -109 -110 File pathFile = new File (path); + 99 File pathFile = new File(diskRepository, prefix); +100 +101 path = pathFile + File.separator; what about line 101 as path = pathFile.getAbsolutePath() + File.separator; ? (In reply to comment #29) > I have a comment about change done in cnd.repository/... Yes, please look over your module's functionality; I tried to leave behavior untouched (when --cachedir not specified) but I do not know how to test things like this. > path = pathFile + File.separator; > > what about > path = pathFile.getAbsolutePath() + File.separator; Sure. Would only make a difference in case pathFile were relative, which I suppose could happen if you passed -J-Dcnd.repository.cache.path=../cndcache. (In reply to comment #30) > (In reply to comment #29) > > I have a comment about change done in cnd.repository/... > > Yes, please look over your module's functionality; I tried to leave behavior > untouched (when --cachedir not specified) but I do not know how to test things > like this. > > > path = pathFile + File.separator; > > > > what about > > path = pathFile.getAbsolutePath() + File.separator; > > Sure. Would only make a difference in case pathFile were relative, pathFile is an instance of java.io.File and it's not very nice 'a+b' expression where toString() is used indirectly (In reply to comment #31) > it's not very nice 'a+b' expression where toString() is used indirectly As you like. (In reply to comment #31) > and it's not very nice 'a+b' expression where toString() is used indirectly Under the hood, always StringBuilder.append() is used. Looking once again at the created API, I believe it offers its users something that they are supposed to never use. The getters are OK, but the setters are only for privileged users (e.g. core.startup) or for unit tests. Nobody else should ever use them. Y01 Remove setters from Places API I can see two ways to do it. Either rely on System properties (as has been the case so far), which is in my opinion OK in tests. Or Lookup.getDefault().lookup(Places.class) implemented in core.startup with additional protected abstract findCacheDir() & findUserDir() to call from the getters. Sorry for reopening existing issue, I could/can create new bug, if desired. (In reply to comment #34) > Nobody else should ever use them. So, do not use them. Is there any evidence that anyone would "accidentally" call these methods? Existing code could already call System.setProperty("netbeans.user", ...) but that was never a threat. A setter with Javadoc explaining its intended scope of usage (and friendly to JPDA breakpoints, logging, Find Usages, etc.) is if anything safer than a system property. (By the way I initially prototyped throwing SecurityException when an attempt was made to change the value once set. This did not work, as usages from TestCase.setUp need to modify an existing value in the same JVM.) > Lookup.getDefault().lookup(Places.class) implemented in core.startup Possible, though this would be more cumbersome for tests; see several test usages in the patch. > I could/can create new bug, if desired. That would be clearer. *** Bug 115670 has been marked as a duplicate of this bug. *** |