- This topic has 10 replies, 2 voices, and was last updated 4 years, 5 months ago by
.
-
Posts
-
Hello everyone,
I use visualGDB 5.5 Preview 5, build 3595 (Custom License) on Windows 10 in VS2017 Pro to Cross-Compile a CMake-based Qt project on a Debian9 – VM running in VMWare Workstation 15.
My project sources reside in the VM in a virtual machine shared folder (so I can easily access them from my Windows host as well) and I directly access the files via SSH.I am experiencing two problems that i cannot seem to get rid of:
- I cannot edit the source files, because of missing file permissions (see attached screenshot).
I can edit the CMakeLists.txt files in my project hierarchy, though.
I can edit the source files externally (e.g. via notepad++) on my windows host since i have access to the code via the VM shared folder. - I cannot “Reload CMake Project” via context menu in my Project Explorer and get a visualGDB Null Pointer Exception (see attached screenshot). If I edit and save any of my CMakeLists.txt files from within my project hierarchy however, the CMake project reconfigures and regenerates successfully.
Any help would be much appreciated, since I cannot see the reasons for this behavior and don’t know if where and how i damaged my project configuration.
Best Regards,
AlexHi,
It looks like the location where you have the project (that is redacted on the screenshot) is not writable to your Linux user account.
Please double-check the mount point permissions and make sure the Linux user can access it. You can quickly check whether a file is writable by running the following command via SSH:
test -w <file path> && echo "Writable"
If you are not sure how to configure mount points, please try placing the project directly inside the home directory on Linux. It should normally be always writable.
Hi and thanks for the fast response.
I ran the test on the VM shared folder where my project resides in and the user I use for logging in (the only configured user in my VM, a sudoer) does have write permissions. Intermittently / just after setting it up I was able to edit source files in said project in the past, that is why I was surprised that I seem to have lost that privilege somehow. Also, the CMakeLists.txt files which reside in the same folder are editable.. is there some thing I could have done to mixup / damage the file access permissions? I do not want to run into this phenomenon over and over, if I set up a clean project again.
I also migrated the project to my home folder and created a new visaulGDB project (import), where I was able to edit and save a source file. However, I do not want my codebase inside the debian VM but rather on my windows host, because I parallely develop the code for windows and want to do that natively.
Btw. the copy of my project in my home folder has the same issue no. 2 as well (I cannot reload the cmake project). Any thoughts?
Cheers,
AlexIt looks like you are testing the entire folder rather than the file shown in the error message.
Please try using a text editor (e.g. nano) to edit exactly the same file that VisualGDB could not access. If it can be saved successfully, it could be a VisualGDB-level issue and we should be able to fix it. If not, it has something to do with the way the folder is mounted and is outside of VisualGDB’s control.
If you want to keep the code base on Windows, please consider selecting it on the “Source code access” page of the wizard. It allows explicitly choosing between keeping the files on Windows and uploading them during build vs. accessing them via SSH vs. other methods.
Sorry for misunderstanding; I failed to edit another file and immediately tested that specific file and do have write permissions via SSH, see attachments.
The same goes if I natively test inside a terminal in my VM.I have experimented in the beginning with the option “Source on windows, upload changed files during build to Linux” but have quickly abandoned it due to problems with inaccurate timestamps, which led to all my codebase being transferred to the linux VM on every build. The direct SSH access and placing the code on a VM shared folder so its accessible from both sides seemed like the best option for my use case.
Thanks for the update. Looks like the file has the write permissions, but might be inaccessible due to other issues (e.g. bug in the shared folder driver).
Please try editing the same file using the:
- The nano editor via SSH.
- SmarTTY’s editor in the smart terminal mode (File->Open Remote File).
Please let us know whether each of these options works.
Hello again,
after working on another project, i am revisiting my pertaining issue with write permissions.
As requested, I tried to edit a source file natively in VS, which was not possible. I then tried the following options:
- Editing the exact file with an SSH console and nano -> works.
- Opening a new smarTTY Session in a separate window:
- editing the exact file with nano -> works.
- editing the exact file with the smarTTY built-in editor -> works, but asked me if I want to convert CRLF into LF [yes].
So, as far as I understand, the file permissions are there, except if i am using the VS built-in editor to edit the file (this is not limited to one file but all source files EXCEPT the CMakeLists.txt files).
Please let me know what else I could do to help you debug this.Cheers,
AlexSo, as far as I understand, the file permissions are there, except if i am using the VS built-in editor to edit the file (this is not limited to one file but all source files EXCEPT the CMakeLists.txt files).
Unfortunately, I have to revise my own previous statement. For the first time, i am also unable to edit a CMakeLists.txt file right now.
To add insult to injury, i cannot launch a new SSH console because it says “No active SSH session”.
The SSH connection to the VM works when I test the conenction via the SSH conenction manger though. From there, I can also launch a console, which defaults to smarTTY. With both nano and the bult-in editor I can edit the CMakeLists.txt in question.
At least that makes the issue somewhat more consistent, because it was inexplicable to me why there are no issues with CMake files but only source files..
Thanks, it looks like the permissions are indeed OK. Please try the following steps to obtain more diagnostic context:
- Open View->Other Windows->VisualGDB Diagnostics Console and enable it.
- Try saving the file again.
- Check the diagnostics console for any error messages produced while saving the file and post them here.
Hi,
I enabled the diag console, cleared contents, tryed to save the SMAkeLists.txt and got the following diag output:
Uploading 1 file(s) with SCP... failed to upload /mnt/hgfs/vmshare/codebase/coreapps/myEXE/CMakeLists.txt: LIBSSH2_ERROR_SCP_PROTOCOL while trying to upload /mnt/hgfs/vmshare/codebase/coreapps/myEXE/CMakeLists.txt ------------------ je2 ------------------ je2: LIBSSH2_ERROR_SCP_PROTOCOL while trying to upload /mnt/hgfs/vmshare/codebase/coreapps/myEXE/CMakeLists.txt at dq1.g2(String d, Int64 c, DateTime a, Nullable`1 b) at vl2.u(String c, List`1 e, vo a, a d, nr1 b) Uploading 1 file(s) with SCP... failed to upload /mnt/hgfs/vmshare/codebase/coreapps/myEXE/CMakeLists.txt: LIBSSH2_ERROR_SCP_PROTOCOL while trying to upload /mnt/hgfs/vmshare/codebase/coreapps/myEXE/CMakeLists.txt ------------------ je2 ------------------ je2: LIBSSH2_ERROR_SCP_PROTOCOL while trying to upload /mnt/hgfs/vmshare/codebase/coreapps/myEXE/CMakeLists.txt at dq1.g2(String d, Int64 c, DateTime a, Nullable`1 b) at vl2.u(String c, List`1 e, vo a, a d, nr1 b)
Sorry, the LIBSSH2_ERROR_SCP_PROTOCOL error means that the remote target has rejected the file upload, so the problem is not on the VisualGDB side. Based on what you have described, the problem appears intermittent, so some random circumstances may increase its chance of being triggered.
If the target path is a shared folder that is available on Windows anyway, please consider setting up a manual path mapping instead. See the attached screenshot for more details.
- I cannot edit the source files, because of missing file permissions (see attached screenshot).
- You must be logged in to reply to this topic.