If you have a Standard user account (or if you are willing to switch your account to Standard and create a separate Admin account), the solution exists. If your user is of the Administrator type (rather than a Standard account), there's no way to run VB with symlinks working without the UAC prompt. I have done some Windows research on this bug. I know NTFS knows what they are and I think there are two different methods of setting them up. I wonder what hosts don't understand sym-links also. I was going to say that a lack of this feature is going to force me to switch to an NFS server on the host mounted on the guest but that creates more complication because I'll have to mount the same drive as CIFS for my windows guest. solution was precisely because this works and the shared fs thing seems to perform so much better. The reason I chose VirtualBox altogether instead of. I mention this because I depend heavily on the symlinks working on the shares and my alternative is to use an NFS server. Anyway, I don't think NFS tries to stop this. It isn't terribly secure, but there you go.
if you mounted an nfs share at /foo that contained some symlink to /bar/file then if you had a /bar/file, it would resolve to your local copy, no? If you didn't have a /bar/file, it would dangle. Isn't that what happens if you mount an NFS share? I.E. Too many users/applications were caught by surprise by the non-standard behavior. This can't be done quickly, so the only option was to disable symlink creation. It's of course fixable, but far from trivial as the separation of symlink processing between guest OS side and host side needs to be redesigned. if a symlink on a shared folder mounted at /foo would point to /bar/file it's impossible to do the right thing on the host side). For compatibility with guest OSes which have no idea what a symlink is it is at the moment interpreted on the host side, and this means one get unexpected behavior with guest OSes which know what a symlink is (e.g. This change is intentional, and fixes a problem with the current implementation of shared folders.
0 kommentar(er)
