Currently I am using macOS Microsoft Remote Desktop 10 to connect to a virtual machine. Within the settings of this Microsoft Remote Desktop 10 application, I set the re- direct folder to the disk image I create in objective C; therefore, in the RDP'd virtual environment, I am able to access the \tsclient\drive that I created in macOS.
If I disconnect and re connect the disk image in macOS, in the RDP'd virtual environment, I am unable to access the \tsclient\drive as it says
"\tsclient\drive is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Attempt to access invalid address."
This is not a problem in Microsoft Remote Desktop 8 as if I disconnect and reconnect the disk image in macOS, I am still able to access it in the RDP'd virtual environment.
Here is how I create / attach a disk image.
I first set the launchPath to "hdiutil" and I then set the arguments to; create, -size, -type, -fs, & -volname
I then do:
[createImage launch];
[createImage waitUntilExit];
On attaching the image, I set path to hdiutil and then set arguments to; attach.
I also repeat the code above with a new task.
On disconnecting the drive, I set the task and path to hdiutil and then set the arguments to; detach, -force.
I then do:
[detachImage launch];
[detachImage release];
[detachImage waitUntilExit];
This has no problem in MICROSOFT Remote Desktop 8; but like I said, in MICROSOFT Remote Desktop 10, if I disconnect and re connect and verify on macOS the disk image is there, in the RDP'd virtual environment, I am unable to access the network disk image (tsclient\drive).
I tried and replicated this issue by using the hdiutil commands in macOS rather than in objective C, so it is replicatable in terminal and in code using nstask.
The commands I used in terminal are;
hdiutil create ~/.test/drivemap -size "384m" -type "SPARSE" -fs "HFS+" -volname "drive"
hdiutil attach ~/.test/drivemap.sparseimage
hdiutil detach -force /Volumes/drive
How do I squash this bug that is not in Microsoft Remote Desktop 8 but rather in Microsoft Remote Desktop 10.
