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, I'd like very much to use the Smart Secure Copy feature to remote build C++. Unfortunately the remote copying seems to corrupt the file. I'm using the test Arguement_1 project supplied with the IDE. When I look at the remote args.c file via od args.c I see: 0000000 000000 000000 000000 000000 000000 000000 000000 000000 * 0003460 000000 000000 000000 000000 000000 000000 000000 005000 0003477 This is common to what seems like all the copied files, and makes remote building unworkable - with errors like: "src/args.c", line 1: null character in input The remote box is: uname -a SunOS fftusd7730 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Fire-V440 Plus using: NetBeans IDE 6.8 (Build 200912041610) Kind Regards spalj
Hi, I'd like first to explain how secure copy works. Smart secure copy works as follows. First, it creates file structure, on the remote host, but makes files empty. Then, while running build, it delivers necessary upon request (i.e. when build tries to open files). So at some moment files can contain nulls at remote host. So, in the case your build breaks for some reason, it will sure left some files empty. I just checked build on remote Solaris 10 on Sun-Fire-V440, and wasn't able to reproduce situation. So I need you to answer some questions. What is your remote tool chain - GNU? Sun? Which version? If you build the project, what is the content of the output window? Could you run IDE with additional options -J-Ddlight.logger.level=0 -J-Dcnd.cloud.logger.level=0 and attach NetBeans message log here?
An idea came to my mind: the answer might be quite simple. If your project is created using absolute paths, it won't work with remote. Only relative paths work. This can be set via Options -> C/C++ -> Project Options -> File Path Mode. If your File Path Mode isn't "Always relative", change it to "Always relative" and recreate the project.
According to the reporter's response (in mail), that's not about absolute/relative paths. Investigating...
At last the reason was found (John, thank you very much for your cooperation!). To reproduce the situation, create a user on remote host that have his home in a directory that is symbolic a link. RFS does not work for such remote user. That's because when opening files make resolves symbolic links, while RFS does not take this into account (when it determines whether a file is controlled or not).
fixed with http://hg.netbeans.org/main-silver?cmd=changeset;node=464446486be3 http://hg.netbeans.org/main-silver?cmd=changeset;node=c23508be3e73 http://hg.netbeans.org/main-silver?cmd=changeset;node=30d50e68a3cf
*** Bug 181378 has been marked as a duplicate of this bug. ***
Is this bug marked for patch 2?
Please verify this issue in trunk (6.9) if you want to see it in 6.8 patch
I had e-mail discussion with reporter of this issue and got this reply --BEGIN----------------------------------------------- Hello, That trunk version has the same problems as before. Rgds John --END------------------------------------------------- Backgroud: the trunk version mentioned is build from http://bits.netbeans.org/dev/nightly/2010-03-05_02-00-36/ I've also asked reporter to note comments found earlier in this issue --BEGIN----------------------------------------------- #1 Could you run IDE with additional options -J-Ddlight.logger.level=0 -J-Dcnd.cloud.logger.level=0 and attach NetBeans message log? #2 the answer might be quite simple. If your project is created using absolute paths, it won't work with remote. Only relative paths work. This can be set via Options -> C/C++ -> Project Options -> File Path Mode. If your File Path Mode isn't "Always relative", change it to "Always relative" and *recreate* the project. --END------------------------------------------------- I don't have a response yet. I hope reporter will attach the messages.log I'm tempted to reopen this issue, but will wait for additional information to come from reporter.
Rudolf, thank you for the information. The user's issue might me cased by the issue 181378, which isn't fixed yet. It is also related to symbolic links, but on the local side.
OK, will keep an eye on issue 180745 and issue 181378 just in case they could make it into 68patch2. At this very moment the chance is not high, unless it would get escalated.
Created attachment 94968 [details] messages.log from reporter I've received the messages.log from reporter. I can see in the logfile, that additional arguments were used, but I can't find smart secure copy or remote compilation related messages.