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.
we want to connect to a windows server using ssh and browse the remote hard drive; then we install in the server cygwin to use ssh and we can connect to it using command line or netbeans without any problem. When we use Remote File Chooser to browse the disk we cannot access to some folder inside the drive, for example C:\Program Files (that become /cygdrive/c/Program Files) is not accessible. It is easy to reproduce using Tools -> Options ->C/C++ -> Set the host values and try to use the browse button to set an executable for C++ suite. Some clues doing debug: 1. I saw that the problem is in org.netbeans.modules.nativeexecution.api.util.FileInfoProvider.StatInfo.can(...), the method took the wrong "uid" and "gid" to check the permissions. 2. I suppose the problem was the cygwin implementation of ls. If using the command line we connect to windows machine and we try "ls -l" we see that the user column and group column are swapped. May be the real problem. Thanks in advance -Paolo
I'm sorry to say that but the remote feature is only supporting Linux and Solaris as remote platforms. It does not mean it can not work with anything else (it evidently works with FreeBSD for example). However it does mean that we've never tested on other platforms and do serve them on "will do our best" [no commitment] principle. That said I can not confirm this issue as a P2 one. Still we will look into this and try to fix in next release. On your side you can help with collecting some diagnostic info/logs (the responsible developer will communicate you with the instruction), testing the fix (we have n environment to test on) and may be, if you will, even with a code contribution to enable faster resolution. As you have some ideas about what's wrong it might be not that difficult to do (another very probably root cause could be a space in the "remote" path). Leonid
Some technical comments. > 1. I saw that the problem is in > org.netbeans.modules.nativeexecution.api.util.FileInfoProvider.StatInfo.can(...) > the method took the wrong "uid" and "gid" to check the permissions. uid and gid are numeric and are gotten via sftp, so it's unlikely that IDE gets them wrong for the file. But probably (I didn't check this) IDE get them wrong for the current uset (it's HostInfoUtils.getHostInfo method who is responsible for that). > 2. I suppose the problem was the cygwin implementation of ls. We don't parse ls output, we get listing via sftp, so this assumption is wrong I believe.
Yes thanks, as we supposed the guilty was pure CYGWIN (wrong permissions). We found another freeware SSH Server (MOBASSH Server Home) and Remote File Browse works much better without any privileges problem. Now we have another problem when we kill an executable launched using NativeProcessAPI in the local machine under Windows We are in windows 7 machine, without ssh or cygwin installed. We create a new local process builder using NativeProcessBuilder.newLocalProcessBuilder(); pb.setExecutable(executable); pb.setArguments(args); // we set the descriptor pb.call(); The job starts without any problem. If I kill it using the process.destroy() a NPE occurs in SignalSupport line :99 It seems like the WindowsSupport.init(String str) is not be able to retrieve the windows shell because it is searching for a sh.exe executable or something like that: then it is assuming that cygwin or something similar is installed. Is there any way to work around this or I have to use External Execution for the execution of local processes? Thanks in advance -Paolo
Created attachment 109420 [details] The NPE stackTrace
Hi, epele83! Well.. looks like this should be fixed in NB itself.. But not sure if we can do this in time for the current release (I'll file a separate issue for this. But it will not be a high-priority issue). For work-around you can try to do the following: As you see, the information about shell comes from a HostInfo: hostInfo = HostInfoUtils.getHostInfo(execEnv); then shell is taken as String shell = hostInfo.getShell(); and this is null in your case. You can implement your own HostInfoProvider that will return correct shell (do you have any? you can, actually, take one from, say, msys (sh.exe) and deliver it with your product and return reference to it... ) As an example of provider implementation see WindowsHostInfoProvider. And don't forget to make yours registered _before_ existent one (for this use position param in @ServiceProvider annotation... Hope this will allow you to proceed.. =Andrew