Opened 10 years ago
Last modified 10 years ago
#14403 new defect
Symlinks are created incorrectly on shared directories
Reported by: | MathiasB | Owned by: | |
---|---|---|---|
Component: | shared folders | Version: | VirtualBox 5.0.0 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Windows |
Description
I have a trusted environment for development and I have activated symlink support for shared folders as desribed here: https://www.215389.xyz/ticket/10085
This solution worked great so far, however since VirtualBox 5 (in combination with Win 10 host), the creation is incorrect.
If I create a symlink on a shared folder with the command
ln -s /media/sf_data/file.js /media/sf_data/test.js
The symlink is created but using readlink, I can see that the created path is incorrect:
\media\sf_data\test.js
The backslash should be replaced by a slash.
If I create a symlink outside the shared folder, everything is correct. Also if I create a symlink pointing to a file in a shared folder. However if I create a symlink within a shared folder to a file outside the shared folder, the bug exists.
Change History (3)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Please let us know if this build helps: https://www.215389.xyz/download/testcase/VirtualBox-5.0.3-102224-Win.exe
comment:3 by , 10 years ago
Just tested with 5.0.3-102322-Win, and symlinks display proper path. However, there's one thing remains broken.
We use VBox+Vagrant combo for nodejs development. As you may know, there's a problem with npm recursive directory structure that windows cannot handle, therefore we install node_modules outside the share folder maintaining only symlink there. So assume:
mkdir /var/node_modules ln -s /share/node_modules /var/node_modules
Symlink is created and displays proper path. Now when you try to install npm i phantomjs
it won't work, npm throws some senseless error messages. BUT! Once you do this:
mkdir /var/node_modules ln -s /share/node_modules /var/node_modules ln -s /var/node_modules /share/node_modules
It works without any problems as if it was running under native Linux OS.
I cannot tell if this is a VritualBox issue or third-parties, but since resolution step requires only ln -s
command this may be relevant.
True for 5.0.1-101957-Win build as well.