Bug 49813 - On MS Windows don't use unconventional/inconvenient leading-'.'-names
On MS Windows don't use unconventional/inconvenient leading-'.'-names
Status: NEW
Product: platform
Classification: Unclassified
Component: -- Other --
7.0
PC Windows XP
: P3 (vote)
: TBD
Assigned To: issues@platform
issues@platform
:
Depends on: 196075
Blocks: 207506 207507
  Show dependency treegraph
 
Reported: 2004-10-01 17:50 UTC by ulfzibis
Modified: 2014-02-14 12:13 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo