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.
Hello, i hope i do no mess by filing a "defect bug" for this issue. On my machine (windows xp sp3, netbeans 6.8, installed php module) i cannot create any file called "aux", with any extension. Actually i tried to create a file "aux.css" for a web project. The new-file-dialog says "system cannot find file" (in german: "Das System kann die angegebene Datei nicht finden"). This also happens for class "Aux", when creating a new Java-Class, creating empty file "aux", etc. All projects i tried are under svn-control. This is no big problem at all, but i can imaginge this issue having an effect when importing a bulk of files into a project, where one or more files have been created outside netbeans with the name "aux". Thank you, Greetings konrad
Unfortunately Windows has problems with a handful of filenames, including "aux" which going back to DOS times was a special device name. http://msdn.microsoft.com/en-us/library/aa365247.aspx#naming_conventions
Hell, yeah, that's it, ohmygod. Sorry to bother you with such silly stuff. Darkly i can remember such names, "lpt" and "con" and "com1". Anyway, there might be a problem (at least for me), i use netbeans on linux and windows, and i share projects using svn. It is possible on linux to create files called "aux" without any warning, wich means, these will cause an error when the project is svn-updated on a windows machine? So, I know about this issue now, but a warning message about those filenames would be really nice. Thank you very much and Greetings konrad
(In reply to comment #2) > It is possible on linux to create files called "aux" without any warning, which > means, these will cause an error when the project is svn-updated on a windows > machine? Yes, it is possible. Also to create Something.java and SomeThing.java which a Windows or Mac client cannot have coexist. Even making a file path too long (>250 characters if I remember correctly) can break on Windows, which is hard to defend against since the length of the directory in which the project is checked out counts toward this total. And various operating systems may or may not be able to handle different Unicode subsets in filenames, or certain punctuation characters. Modern Linux distributions seem to have the fewest issues, Solaris and Mac OS X some more, and Windows is a constant battle. Whether all this is a real problem or not depends on how you work. Some people may be in teams that only use a particular OS and be fine with that. Or your version control system may be configured to reject attempted commits with problematic filenames, or a style checker on a continuous integration server may flag such things. If you do encounter an error of this kind, the problem can simply be fixed on the originating machine (e.g. Linux) and the next svn up should work, as far as I know. I only have direct knowledge in the case of Mercurial: since 1.1, its repository storage format specifically protects against all these cases, since the repository is append-only (i.e. you cannot retroactively remove an entry); but any given revision of the working copy might have problematic filenames, which can be worked around by updating to a fixed revision. I was one of the contributors to this change in Mercurial, since when using 1.0 some of my Windows-using colleagues were unable even to clone the NB source repository due to a few extremely long subpaths; now those paths have been trimmed, and the new repo format caps storage filenames at around 100 characters which is generally safe. Anyway, this is a complex subject and it is probably out of the scope of the IDE to enforce a particular policy.
Well, i see now that this is not an issue wich is simply solved by adding a blacklist with some "dangerous" filenames. Thank you very much for your time, Greetings Konrad