Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 187156 - Remote build does not work if ${HOME}/.netbeans/remote/ is a symbolic link
Remote build does not work if ${HOME}/.netbeans/remote/ is a symbolic link
Status: RESOLVED WONTFIX
Product: cnd
Classification: Unclassified
Component: Remote
6.x
All All
: P3 (vote)
: TBD
Assigned To: Vladimir Kvashin
issues@cnd
69patch1-verified
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-03 16:43 UTC by Vladimir Kvashin
Modified: 2012-10-30 21:09 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
messages.log (105.69 KB, text/plain)
2010-08-04 10:21 UTC, LiveFreeAndRoam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Kvashin 2010-06-03 16:43:24 UTC
Remote build does not work if ${HOME}/.netbeans/remote/ is a symbolic link:Makefile:1: warning: NUL character seen; rest of line ignored
Comment 1 ardashev 2010-06-04 21:02:06 UTC
include directories are not found by C++ code assistant if they are symbolic links on linux,  C++ code assistance configuration does not work with objects or executable or libraries, only with makefile log, whre I have to replace all linux style directories like /home/user/ with windows style Z:/, even though the path mapper is told that it is the correspondence. All of this happening with netbeans on windows and samba mounted linux filesystem. secure-copy mode does not work at all failing to sync files.
Comment 2 ardashev 2010-06-04 21:04:52 UTC
include directories are not found by C++ code assistant if they are symbolic
links on linux,  C++ code assistance configuration does not work with objects
or executable or libraries, only with makefile log, whre I have to replace all
linux style directories like /home/user/ with windows style Z:/, even though
the path mapper is told that it is the correspondence. All of this happening
with netbeans on windows and samba mounted linux filesystem. secure-copy mode
does not work at all failing to sync files.
Comment 3 Vladimir Kvashin 2010-06-06 07:15:00 UTC
Thank you for information.

> I have to replace all linux style directories like /home/user/ 
> with windows style Z:/, even though the path mapper 
> is told that it is the correspondence

I filed a separate issue 187235 in this respect
Let's leave this one for inability to build.


> include directories are not found by C++ code assistant 
> if they are symbolic links on linux
I don't quite understand the issue.
Could you please describe it in more details in a separate IZ?

Thank you.
Vladimir
Comment 5 Quality Engineering 2010-06-08 06:06:44 UTC
Integrated into 'main-golden', will be available in build *201006080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a4d912822720
User: Vladimir Kvashin <vkvashin@netbeans.org>
Log: fixed #187156 -  Remote build does not work if ${HOME}/.netbeans/remote/ is a symbolic link (source update)
Comment 6 rbalada 2010-06-16 08:55:28 UTC
Please verify bugfix for this bug, so it can be included in release691 repository.

Thanks,
-R
Comment 7 Alexander Pepin 2010-06-18 14:44:42 UTC
verified in trunk
Comment 8 rbalada 2010-06-21 15:28:36 UTC
main #a4d912822720 transplanted to release691 #330c394b6ea4
main #8d437c5010dd transplanted to release691 #49ccdb4cf24c
Comment 9 soldatov 2010-07-08 10:56:32 UTC
verified in 6.9.1 build
Comment 10 LiveFreeAndRoam 2010-08-02 11:51:56 UTC
This problem still exists in V1.10 NetBeans IDE Dev (Build 201008020001).  Client=Vista, Server=Linux.

Simple test.

1) Created a C project (myNbProj) and configured it with a remote host.  Ran the build and all files were uploaded successfully to:

 cd ~/.netbeans/remote/client-Windows-x86_64/C/Users/lfar/Documents/Work/myNbProj


2) On the remote host, modify the project root to be a softlink.  e.g.

 cd ~/.netbeans/remote/client-Windows-x86_64/C/Users/lfar/Documents/Work
 mv myNbProj myNbProj.sav
 mkdir /work/myNbProj
 ln -s /work/myNbProj

3) Now reissue the Build and all files are filled with NULLs.

hexdump /work/myNbProj/Makefile
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0001180 0000 0000 0000 0000 0000 000a
000118b

LFaR.
Comment 11 LiveFreeAndRoam 2010-08-03 05:43:35 UTC
(In reply to comment #10)
> This problem still exists in V1.10 NetBeans IDE Dev (Build 201008020001). 
> Client=Vista, Server=Linux.
> Simple test.
> 1) Created a C project (myNbProj) and configured it with a remote host.  Ran
> the build and all files were uploaded successfully to:
>  cd
> ~/.netbeans/remote/client-Windows-x86_64/C/Users/lfar/Documents/Work/myNbProj
> 2) On the remote host, modify the project root to be a softlink.  e.g.
>  cd ~/.netbeans/remote/client-Windows-x86_64/C/Users/lfar/Documents/Work
>  mv myNbProj myNbProj.sav
>  mkdir /work/myNbProj
>  ln -s /work/myNbProj
> 3) Now reissue the Build and all files are filled with NULLs.
> hexdump /work/myNbProj/Makefile
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0001180 0000 0000 0000 0000 0000 000a
> 000118b
> LFaR.

A little more testing reveals the bug is more serious than I first thought.  Basically, files were filled with NULL, regardless of there being a softlink in the path or not.

On the server, I wanted to clean things up and start over.

rm -fr ~/.netbeans

Back on my Windows client, I right-clicked my project and selected "Build".  This caused the files and directory structure to be reestablished on the server, except every file contained NULLs.

Next attempt, I cleaned things up again on the server (rm -fr ~/.netbeans).  This time, I right-clicked my top-level folder and selected "upload to server".  Only a subest of files were uploaded successfully (*.[ch]).  Can I upload all files (regardless of their type?

So it appears the "Build" option is broken (regardless of there being a symbolic link in the path) and the "Upload to server" option only works for *.[ch] files.

This testing was performed on NetBeans IDE Dev 201008020001.

Kind regards,
LFaR.
Comment 12 LiveFreeAndRoam 2010-08-04 10:21:40 UTC
Created attachment 101188 [details]
messages.log

Hi soldatov,

I really appreciate your help with this.  It has become a real problem for me.

As requested, I've attached the messages.log.  I've had to edit the log file to remove identifying information.  I've also removed numerous entries that logged the files being uploaded, though I kept a couple of entries which were similar to all the others.  You will see this in the log file, as I've marked it with <<<LFaR: .... >>>

  The command-line I used to start NB6.9 was:

 "C:\Program Files\NetBeans 6.9\bin\netbeans.exe" -J-Duser.name="LiveFree AndRoam <LiveFreeAndRoam@gmail.com>" -J-Dcnd.remote.logger.level=0 -J-Dnativeexecution.support.logger.level=0

Please let me know if you need more info.

Kind regards,
LFaR.
Comment 13 LiveFreeAndRoam 2010-08-05 06:16:37 UTC
I found a workaround by using the unsupported SCP method.  i.e. I started NB with the following option added to my command line: -J-Dcnd.remote.scp=true

Then in the "C/C++ Development Hosts" properties, I selected "Secure Copy" from the Synchronization drop-down.

Once again I cleaned the server (rm -fr ~/.netbeans) and then right-clicked my project and selected "Build".

All the files were uploaded correctly.

I also saw some warnings, which may simply be an artefact of this unsupported feature, or it may point to the cause of the NULL files.  In any case, to be complete, here are the warnings I see using "Secure Copy":

Copying project files to /home/mattm/.netbeans/remote/lfar-Windows-x86_64 at lfar@myserver.com:22
make: Warning: File `nbproject/Makefile-variables.mk' has modification time 6.1e+04 s in the future
make[1]: Warning: File `nbproject/Makefile-variables.mk' has modification time 6.1e+04 s in the future

make[2]: Warning: File `Makefile' has modification time 6.1e+04 s in the future
make[2]: warning:  Clock skew detected.  Your build may be incomplete.
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
make: warning:  Clock skew detected.  Your build may be incomplete.

Cheers,
LFaR.
Comment 14 LiveFreeAndRoam 2010-08-05 22:40:23 UTC
FWIW, I just tested 6.9.1, and the results were identical to 6.9.  i.e. the Build command copies NULL-filled files to the server. :(.

Once again, selecting "Secure Copy" from the host properties provided a workaround.

LFaR.
Comment 15 Vladimir Kvashin 2010-08-06 13:01:59 UTC
LFaR,

Thank you very much for your input. I'm finally able to repeat your situation. 

The scenario you used have some minor differences from the one I kept in mind when fixing this bug; I'm surprised that these differences matter. I'll fix this ASAP.
Comment 16 LiveFreeAndRoam 2010-08-25 00:36:19 UTC
(In reply to comment #15)
> LFaR,
> Thank you very much for your input. I'm finally able to repeat your situation. 
> The scenario you used have some minor differences from the one I kept in mind
> when fixing this bug; I'm surprised that these differences matter. I'll fix
> this ASAP.

Hi Vladimir,

Would you mind if I asked for an update on this case?  I'm new to the NetBeans community, so if this is inappropriate protocol, then I'll be happy to be told so.

Kind regards,
LFaR.
Comment 17 Vladimir Kvashin 2010-09-08 12:57:55 UTC
In reply to #16:

This is the proper place to ask about the state of a bug.

This one isn't fixed yet, sorry.

To work this around, you can soft link the entire ~/.netbeans/remote to a directory, this should work.
Comment 18 cwpetersen 2011-07-28 16:23:54 UTC
(In reply to comment #17)
> In reply to #16:
> This is the proper place to ask about the state of a bug.
> This one isn't fixed yet, sorry.
> To work this around, you can soft link the entire ~/.netbeans/remote to a
> directory, this should work.

Any update on this issue? 

If there is a workaround with the softlink could you please give a few more details?

I tried the softlink workaround with "automatic copy" and "sftp" and it still has problems. "automatic copy" will produce some empty files. "sftp" wont copy all files. For instance *.mk files needed in my build are not copied.
Comment 19 mathewfer 2012-03-03 06:43:58 UTC
Hi All,

Any advice or update on this is much appreciated as I also want to use a unix link to change the default path ($HOME/.netbeans/remote) to something other directory on remote host. I mean to change the default($HOME/.netbeans/remote) remote host directory.

Thanks for any idea/help on this.

Mathew
Comment 20 Vladimir Kvashin 2012-05-10 06:17:45 UTC
Does not repeat any more. To check this I changed each directory on the way
/home/${user}/.netbeans/remote/${rhost}/${lhost}-SunOS-x86_64
to a link, and each time it works perfect.

I think it was fixed a while ago (as a side effect of other fixes).
Comment 21 kandel3 2012-05-22 21:22:44 UTC
(In reply to comment #20)
> Does not repeat any more. To check this I changed each directory on the way
> /home/${user}/.netbeans/remote/${rhost}/${lhost}-SunOS-x86_64
> to a link, and each time it works perfect.
> 
> I think it was fixed a while ago (as a side effect of other fixes).
Hey Vlad,
I am using 201204101705 and I am still getting this null copy error. My main.cpp file appears as all nulls when using the Automatic copying option.
Comment 22 danjaredg 2012-09-06 00:28:52 UTC
The bug stille on 7.2
Comment 23 Leonid Lenyashin 2012-10-30 21:09:32 UTC
There was no activity on this issue for quite a long time. We apologize that the issue was not addressed so far due to lack of development resources. We might not have time in near future to fix this problem, so it is closed as WONTFIX.
If the issue is still critical for you please do not hesitate to REOPEN it.
Thank you for using our product and reporting bugs. We are really sorry that we were not able to fix this issue timely.

Regards,
CND team.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo