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.
This bug was originally marked as duplicate of bug 198082, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE 7.3 Beta 2 (Build 201211062253) VM: OpenJDK Client VM, 20.0-b12, OpenJDK Runtime Environment, 1.6.0_24-b24 OS: Linux Stacktrace: java.io.FileNotFoundException: Can't read /home/joan/Baixades/jpgraph-3.5.0b1/src/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph/Examples/jpgraph at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj.getInputStream(FileObj.java:171) at org.openide.filesystems.FileUtil.copyFileImpl(FileUtil.java:763) at org.openide.filesystems.FileObject.copy(FileObject.java:154) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.copy(BaseFileObj.java:255) at org.openide.loaders.FileEntry.copy(FileEntry.java:76) at org.openide.loaders.MultiDataObject.handleCopy(MultiDataObject.java:515)
Created attachment 131257 [details] stacktrace
It might help if the copy operation could detected symlinks and instead of copying it, rather recreated it somehow.
Created attachment 141838 [details] Proposed Patch > It might help if the copy operation could detected symlinks and instead of > copying it, rather recreated it somehow. It is not clear how the symlinks should be recreated (use the same relative/absolute target path, or create link to source link?). We also cannot always assume that symbolic links should not be followed. The proposed patch simply tries to detect problematic recursive symbolic links and skips them.
Please note that the attached patch doesn't work with Windows junctions, Files.isSymbolicLink(pathToJunction) returns false. Symlinks created e.g. with command "mklink" work correctly.
Reported for 7.3.x or earlier, no new info since then -> closing as worksforme, please reopen in case you see it.