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.

Bug 221039 - Folders named "App" at the top level of a project are automatically lower cased to "app"
Summary: Folders named "App" at the top level of a project are automatically lower cas...
Status: RESOLVED WORKSFORME
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Subversion (show other bugs)
Version: 7.2
Hardware: PC Windows 7
: P2 normal (vote)
Assignee: Ondrej Vrabec
URL:
Keywords:
Depends on: 217919
Blocks:
  Show dependency tree
 
Reported: 2012-10-29 16:00 UTC by cballinger
Modified: 2012-11-02 09:12 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Screen capture of Projects, Files, Favorites and Explorer (65.88 KB, image/png)
2012-10-30 15:08 UTC, cballinger 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description cballinger 2012-10-29 16:00:04 UTC 
This issue occurs in 7.2 and 7.3, but could not be reproduced in 7.1. 

Steps to reproduce:
Open a project with a folder named "App" at the top level. Close NetBeans with the project open. Reopen NetBeans.

Result:
The folder is automatically lower cased to "app" in NetBeans.

This creates significant issues with version controlled projects as NetBeans now sees all the files under the now renamed "app" folder as new unversioned files.

This has been tested on Windows 7 using NetBeans 7.2 and 7.3 and OSX 10.7.5 Lion on NetBeans 7.2.
Comment 1 Petr Jiricka 2012-10-30 14:38:03 UTC 
Does this happen for all kinds of projects, or just some?
Comment 2 cballinger 2012-10-30 14:50:16 UTC 
We're using the PHP version of NetBeans. It's been tested using both New Project > PHP Application and New Project > PHP Application with Existing Sources. Selecting different PHP versions in the dialog also doesn't appear to have any effect on the result.
Comment 3 Jaroslav Tulach 2012-10-30 14:56:52 UTC 
Show me picture of Projects, Files and Favorites view, please.
Comment 4 Jaroslav Tulach 2012-10-30 14:57:04 UTC 
Show me picture of Projects, Files and Favorites view, please.
Comment 5 cballinger 2012-10-30 15:08:14 UTC 
Created attachment 126784 [details]
Screen capture of Projects, Files, Favorites and Explorer

Thanks
Comment 6 Jaroslav Tulach 2012-10-31 18:13:51 UTC 
Interesting. Not that I would have a clue what is going on.
Comment 7 Jaroslav Tulach 2012-11-01 07:13:20 UTC 
I'd like to get clarification on the priority. What exactly is the negative effect of the bug? Does it really deserve P2 priority?
Comment 8 cballinger 2012-11-01 12:49:02 UTC 
Our primary issue is that it affects Subversion negatively. The project was actually started in 6.9 which functioned correctly, but now we're seeing commits into our repo with file paths like /app/ instead of /App/. As Subversion is case sensitive, new files are being created instead of the correct file being updated.
Comment 9 Jaroslav Tulach 2012-11-01 15:48:29 UTC 
The way we present a directory inside of NetBeans IDE should have no impact on the way Subversion sees it - as it is accessing java.io.File directly. On the other hand, if Subversion believes a file should be lowercase, the IDE will show it as lowercase. Thus your last comment makes me believe this problem is Subversion related.
Comment 10 Ondrej Vrabec 2012-11-01 16:02:34 UTC 
can you make a screenshot of the Subversion view for the whole project? Select the project and from its popup menu call Subversion -> Show Changes. I would like to see the new and missing files there.
Comment 11 Ondrej Vrabec 2012-11-02 09:12:30 UTC 
(In reply to comment #9)
> Thus your last comment makes me believe this problem is Subversion related.
Subversion clients we're using are too clever on Windows/Mac and recognize the difference in "filea" and "FILEA". We would have to normalize every single file we ever get from the IDE.
The problem here is that FileUtil.toFile(FileObject) does not return normalized file in this case (still the old path, i have no idea where it gets it). This makes me believe there's a problem in FileSystems - IMO this is a duplicate or a consequence of bug #217919.

I tried in 7.3 and it seems to work OK.