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.
FileStateInvalidException (in the attachment) is thrown, when the target filesystem ignores some files, that are copied into it. This makes impossible to copy folders, that contains CVS/ subfolders from local file system to CVS file system, because CVS file system ignores CVS/ folders. Can be reproduce on local file system also, when you set "Ignored files" (the attached exception is thrown, when .form files were ignored, but the most important is it for CVS filesystems).
Created attachment 2585 [details] Exception thrown
*** Issue 14869 has been marked as a duplicate of this issue. ***
*** Issue 11354 has been marked as a duplicate of this issue. ***
FileSystems can hide some files. AbstractFileSystem.List.children very often do that. Here described problem arrives after calling fo.createData ("hidden_file"). There are expactation that after such calling such method will be created FileObject. But because this file should be hidden there is not possible to create and return such instance. API doesn`t allow return null so exception must be fired. That`s what can be seen in stacktrace. So perhaps some support for hidden_files as enhancement. I`ll let it in Issuezila for next comments and suggestions.
Target milestone -> 3.3.1.
Set target milestone to TBD
I think that should not be fixed, because FileSystem can hides arbitrary files. So, it`s natural that if FileSystem wants hide some FileObjects, doesn`t distribute them, then would be strange method createData would return such FileObject and then fs.findResource would not be possible to find it. Definitely is not desirable to call delete on FileObject that represents CVS folder. Also rename would be be a little strange. Also CVS folder can be created only inside CVS filesystem and not e.g. publicly call rootOfCvsFs.createFolder ("CVS"). I think that the best thing that can be done is fire exception that it is impossible to accomplish operation and that`s how is it implemented at the moment. Then marked as WONTFIX.
Perhaps FileSystems should provide informational method, that will return list or array of resource names (getPackageNameExt), that are hidden by FileSystem. Or better: boolean isHiddenResource (String). Or both ? Or neither first, nor second ? Or better idea ? Usage: LocalFileSystem lfs = .. AnyFileSystem afs = ..; FileObject lfo = lfs.findResource ("///"); if (afs.isHiddenResource (lfo.toString ()) )
Yes, this can work. Either the copy/paste action must have a way to find out which files it can copy OR the filesystem must be able to provide some special FileObjects just for copy/paste purpose. I also like more the first option.
Reassigning to new module owner jskrivanek.
With masterfs the problem shall be gone, shalln't it?