Custom Query (16363 matches)
Results (667 - 669 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #18374 | duplicate | OS/2 File sharing on MacOS host causes crash when attempting to list contents of share. | ||
| Description |
With the share not Automounted, all is well including assigning a drive letter to the share in OS/2 2.1 via command line. Changing to the new Drive letter at the command line also is fine. Typing dir to list the contents of the shared folder causes and immediate trap 000d. Setting the Shared Folder to Automount and assigning a mount point in the VBox GUI results in the same trap during guest boot up. |
|||
| #18376 | fixed | OS/2 File sharing on MacOS host causes crash when attempting to list contents of share => Fixed in SVN | ||
| Description |
With the share not Automounted, all is well including assigning a drive letter to the share in eCS 2.1 via command line. Changing to the new Drive letter at the command line also is fine. Typing dir to list the contents of the shared folder causes and immediate trap 000d. Setting the Shared Folder to Automount and assigning a mount point in the VBox GUI results in the same trap during guest boot up. |
|||
| #17451 | worksforme | Immutable images take an extra minute before starting to boot | ||
| Description |
I have a VirtualBox image that I use for testing things on a new install of a particular OS. I don't want any changes to be saved after the virtual machine is exited because I want it to always return to the state of a new install for future testing, so I made the image immutable. In VirtualBox 5.1, starting an immutable image immediately went to booting the virtual machine. I just switched from VirtualBox 5.1.30 to VirtualBox 5.2.4, and now starting an immutable image brings up a dialog box that says "Disk Image Reset Operation - Immutable Image", which blocks progress for about a minute before the virtual machine starts to boot. This extra wait is a worse situation than with VirtualBox 5.1. |
|||

