Bug 49813

not valid:
"${APPDATA}/netbeans/4.0beta2"
correction: (german version)
"${HOME}/Anwendungsdaten/netbeans/4.0beta2"
correction: (english version; presumable)
"${HOME}/Application data/netbeans/4.0beta2"

I see this problem first time, changed to the enhancement.

Pasting my reply previously sent as a reply to the NetCAT alias:

> bad:
> netbeans_default_userdir="${HOME}/.netbeans/4.0beta2"
>
> better:
> netbeans_default_userdir="${APPDATA}/netbeans/4.0beta2"

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.

> Renaming a dir's name to ".dir-name" is not supported by Windows. I don't know
the reason, but using such names causes problems...

It is supported. Just try the following in the Windows command prompt:

md .test
ren .test test
ren test .test
rmdir .test

Works fine on my Win XP. Win32 API doesn't prevent applications from creating
files and folders with dots in names in any position.

The fact that Windows File Explorer doesn't allow you to create files and
folders with names starting with a dot is a different story. Once you have such
files/folders on your file system, File Explorer will work with them just fine.

NetBeans has been using files and folders with dots for years on Windows and
never had any problems with them.

> Some Windows programs don't recognize such names.

Then it's a bug in those programs.

> Example:
> I use ZDbackup (www.z-dbackup.de) for backing up my files. The directory
${HOME}/.netbeans" doesn't appear in it's filechooser.

Either ZDbackup has a bug, or it just considers the filenames starting with a
dot to be hidden files.

On Unix-based systems, the leading dot in the name indicates a hidden
file/folder that should not be shown in standard file listings. NetBeans uses
the same name on all platforms. It's a convention on Unix/Linux and causes no
harm on Windows (unless you use other programs that make incorrect assumptions
about the file naming conventions on Windows).

So, this is not a DEFECT. No plans to fix the "dot" part, the "APPDATA" issue
can be investigated further. Not a top priority though. -> P3

*** Issue 57798 has been marked as a duplicate of this issue. ***

reassigne to Radim, new owner of launcher

It can be fixed together with issue #57798. Not a high priority now.

Actualy I do not plan to fix this as I do not consider it to be a problem.

This issue had *1 votes* before move to platform component

(In reply to comment #3)
> 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");

The .netbeans part will be corrected by bug 196075.
But .nbi .nbprofiler .netbeans-derby .netbeans-registration should be treated same, at least moved to AppData folder.

(In reply to comment #10)
> The .netbeans part will be corrected by bug 196075.
> But .nbi .nbprofiler .netbeans-derby .netbeans-registration should be treated
> same, at least moved to AppData folder.


Already tracked:
* .nbi - move under AppData/NetBeans Installer (Issue 207506)
* .netbeans-derby - move under AppData/NetBeans/Derby (Issue 207507)
* .netbeans-registration - no need to change, not used anymore