Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: 1. In the remote CDT launch config, select a connection to a remote system running Windows 2. In "Remote Absolute File Path for C/C++ Application", browse for and select any path 3. Set a breakpoint on org.eclipse.rse.internal.remotecdt.RemoteRunLaunchDelegate#remoteShellExec line 278. 4. Look at remote_command parameter. You should see "chmod +x [path];exit" For instance, my remote_command param is "chmod +x C:/Documents\ and\ Settings/user/rsetemp;exit". There are three problems here for Windows: 1) ";" is not recognized as a command delimeter. Use " && " instead. 2) If the [path] parameter is absolute, it uses a forward slash after the drive letter, which is invalid in Windows. In windows, forward slashes everywhere else in a path are kosher, just not after the drive letter. After stepping through your code, though, I see you just call remotePath.toString() in remoteFileDownload line 255, where remotePath is an instance of org.eclipse.core.runtime.Path. I don't know why Path doesn't just use backslashes for windows and forward slashes for linux. 3) spaceEscapify only works for linux paths. In windows, the backslashes are interpreted as path delimeters, not escape chars. Instead of escaping the spaces, you could just add escaped quotes around the entire path. So, when all the fixes above are put in place, "chmod +x C:/Documents\ and\ Settings/user/rsetemp;exit" would become "chmod +x \"C:\\Documents and Settings\\user\\rsetemp\" && exit" And, incidentally, this valid Unix syntax as well.
Also, is there a reason IHostFile or AbstractRemoteFile don't have more functionality dealing with permissions? There's canRead and canWrite for both of these classes, but why aren't there canExecute, setReadable, setWriteable, setExecutable? I say this because it seems instead of sending the "chmod +x" command to the shell, you could just wrap the target file in an instance of an AbstractRemoteFile, and call setExecutable() (if it existed) on it. Are there plans to make setting/getting permissions more robust in the future?
(In reply to comment #0) > "chmod +x \"C:\\Documents and Settings\\user\\rsetemp\" && exit" > > And, incidentally, this valid Unix syntax as well. > On review, I'm wrong about that. Backslashes aren't valid path delimeters in Unix.
Changed the product from "DSDP" to "Target Management". Seems that's where the bug belonged in the first place.
Drasch do you think that this is relevant for WB?
I agree that we should check whether the remote system is windows style. Unfortunately that's not too easy if we want to do it dynamically -- an "SSH Only" connection can be done to Windows, or UNIX. I think that as a starting point we should use the static configuration that users can do via the SystemType already now. That way we would fix the issue for "Dstore Windows" vs "DStore other": IRSESystemType#isWindows() e.g. if (subSystem.getHost().getSystemType().isWindows()) {...} For the chmod issue, this is legacy code and we could now take advantage of the new IFileService#setFilePermissions() method if it's available (can be checked via IFilePermissionsService#getCapabilities(): IService fs = subSystem.getService(); if (fs instanceof IFilePermissionsService) { IFilePermissionsService ps = (IFilePermissionsService)fs; if (ps.getCapabilties() & IFilePermissionsService.FS_CAN_SET_PERMISSIONS != 0) /*...*/ } -- though I'm slightly more in favor of keeping chmod for now, but only executing it if we're not on windows. Setting "helpwanted", Community patches for would be appreciated for this.
Anna do you want to have a look?
Don't have time for it right now.
Moving into CDT as per bug 267065.
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
