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.
When I try to make a new Java application project at C:\Users\Zian\Desktop, I get a "Project Folder cannot be created." message. I've already tried running SubinACL to reset the security privileges on it. I've attached a log from Process Monitor showing only the events from NetBeans that did not succeed.
Created attachment 78139 [details] Process Monitor log
Can you please attach IDE log?
Created attachment 78409 [details] Messages file
I do not see a issue in the log, can you please attach IDE log after you reproduce the problem and got the "Project Folder cannot be created." message? Next can you create a new folder on your desktop?
I quite certain that I attached the log after reproducing the issue. But, just in case, I've tried again. Yes, using Windows Explorer.
Created attachment 78534 [details] NetBeans log file
Unable to find any problems within log file. Assign to more appropriate category.
The problem is specific to Windows. Explorer.exe tends to set folders read-only when they have a special icon. Strangely, read-only folders can be written files in. NetBeans misinterprets what ReadOnly means on Windows and disallow folder creation. To reproduce: Create folder C:\FOLDER Set it read only using "attrib +R C:\FOLDER" Test that you can write into this read only folder (with any kind of tool) Test that you cannot create a NB Java project using this folder as 'Project Location' Set back this not so read-only folder to normal using "attrib -R C:\FOLDER" You now can create the project. I think the problem can now be fixed.
I can confirm that this works. There is a trick though. Unlike most DOS commands, one cannot simply type "attrib -r" to change the current directory. Instead, one must enter "attrib -r [folder name]".
>filesystems
It is because java.io.File.canWrite() returns false for Desktop and other folders which "pretend" to be read-only on Windows. It is already fixed in upcoming JDK 7. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4939819
v/c