Bug 49813

Summary:	On MS Windows don't use unconventional/inconvenient leading-'.'-names
Product:	platform	Reporter:	ulfzibis <ulfzibis>
Component:	-- Other --	Assignee:	issues <issues.netbeans.org>
Status:	NEW ---	QA Contact:	issues <issues.netbeans.org>
Priority:	P3	CC:	jchalupa
Version:	7.0
Target Milestone:	TBD
Hardware:	PC
OS:	Windows XP
Whiteboard:
Issue Type:	ENHANCEMENT	Exception Report:
Bug Depends on:	196075
Bug Blocks:	207506, 207507

Description ulfzibis 2004-10-01 17:50:03 UTC

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

better:
netbeans_default_userdir="${APPDATA}/netbeans/4.0beta2"

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

Some Windows programs don't recognize such names.
Example:
I use ZDbackup (www.z-dbackup.de) for backing up
my files. The path ${HOME}/.netbeans" doesn't
appear in it's filechooser.

Comment 1 ulfzibis 2004-10-02 00:12:22 UTC

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

Comment 2 Marek Grummich 2004-10-07 13:33:21 UTC

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

Comment 3 Jan Chalupa 2005-04-21 06:10:43 UTC

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

Comment 4 Jan Chalupa 2005-04-21 17:40:50 UTC

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

Comment 5 Marian Mirilovic 2006-08-08 08:30:25 UTC

reassigne to Radim, new owner of launcher

Comment 6 _ rkubacki 2006-08-08 09:52:42 UTC

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

Comment 7 _ rkubacki 2006-11-24 09:01:33 UTC

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

Comment 8 Quality Engineering 2008-12-23 14:33:16 UTC

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

Comment 9 ulfzibis 2011-04-13 15:09:11 UTC

(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");

Comment 10 ulfzibis 2011-08-25 18:54:58 UTC

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.

Comment 11 Jiri Rechtacek 2012-04-03 13:38:51 UTC

(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