Changes between Version 1 and Version 2 of Ticket #10085, comment 58
- Timestamp:
- Apr 28, 2020 9:09:53 AM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #10085, comment 58
v1 v2 1 O Ne problem with the current behavior is certainly the error returned by vboxsf/vboxfs in the guest. On Solaris it is EROFS, on Linux this is EPERM. Of course, both are bogus. We neither deal with a read-only file system nor does the user lack any permissions or privileges. Instead we just do not support creating symlinks from within the guests inside the shared folder. ENOTSUP it should have been which would also have prevented a lot of unnecessary questions as it had made very clear where the problem lies rather then EROFS/EPERM.1 One problem with the current behavior is certainly the error returned by vboxsf/vboxfs in the guest. On Solaris it is EROFS, on Linux this is EPERM. Of course, both are bogus. We neither deal with a read-only file system nor does the user lack any permissions or privileges. Instead we just do not support creating symlinks from within the guests inside the shared folder. ENOTSUP it should have been which would also have prevented a lot of unnecessary questions as it had made very clear where the problem lies rather then EROFS/EPERM. 2 2 That at least should be fixed as long as we do not want to support symlinks/hardlinks this way from inside the guest.