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, When configuring a project running on a remote web site, directories that are symbolic links to some other real directories on the remote server are not shown in project source files. When trying to download source files of the project (right click on "Source Files", "Download..." in contextual menu), some entries for the symbolic linked directories are listed but considered as files, not as directories. And of course, files inside these linked directories structures considered as files in the list are not loaded. Among other drawbacks, when using Netbeans for PHP development and if you consider a symbolic link refers to a library directory you share among several projects on your remote web server, the most annoying for me is the impossibility to use the debugger (xdebug) for this library in your main project context. I considered setting up a separate project for this library in order to, at least, access its files. But breakpoints set on these files are also simply ignored as Netbean may consider these files as part of an isolated project. Which makes sense. For the moment, I did not find any workaround excepted copying the library inside the project directory structure instead of linking it with a symbolic link, which is an ugly solution. I think it would be much appreciated if remote symbolic linked directories could be considered as part of the project structure. Copying files in these directories on local machine for Netbeans internal usage may not be an issue as long as uploading them may also be possible, the remote server transparently placing them back in the real directory.
that's something to be done on php support side (copying from remote location to local one) or platform/filesystem side which currently won't work with symbolic links and/or with remote content? what filesystem are we talking about on linux side?
(In reply to comment #1) > that's something to be done on php support side (copying from remote location > to local one) or platform/filesystem side which currently won't work with > symbolic links and/or with remote content? what filesystem are we talking about > on linux side? No, this a problem with NetBeans file browser. When you are working on project located on a remote server and synchronized through Netbeans ftp/sftp component, when clicking on "Download..." from the contextual menu, the list of files and directories candidates to download are shown, including symbolic links to directories located on the remote end (the file system of the server contains these symbolic links to directories located on the file system of the server itself). The thing is that, even if these these symbolic links are shown and can be selected for download, when starting the download process these symbolic links are simply ignored. I would expect these remote symbolic links to be considered as if they were regular directories as it happens if you are on a shell on the server and you type "cd <symbolic link name>": you can enter this directory pointed by the symbolic link and then handle its files and sub-directories as if they were part of the file tree.
If I understand correctly, this issue says that symbolic links are not downloaded from the remote server - is this correct? If yes, then it is OK because symbolic links *must* be ignored (otherwise they would be overwritten during the next upload). Thanks for reporting.
I agree with you, symbolic links *must* be ignored (otherwise they would be overwritten during the next upload). But I mean symbolic links as symbolic links *must* be ignored, but the thing they represent *must not*. A symbolic link would be considered and handled *AS* a symbolic link and, thus, be used for what it is: a linkage to another part of the file system. As a result, a symbolic link to a directory stored server side should be *considered*, viewed, interpreted as a directory on client side, and thus its content downloaded and uploaded transparently. This is also true for symbolic links to files: it's the file linked by a symbolic link that should be considered on client side, not the symbolic link itself. Managing symbolic links themselves is out of the scope of Netbeans and devoted to administrative tasks run on the server, through a shell for example.
Sorry, changing to enhancement since right now it works as designed.