Deployment: Hosted
EaaSI Version: 1.10.0
Browser: Google Chrome, Version 90.0.4430.212 (Official Build) (x86_64)
Description: When I upload content (files, .SAM to be specific) in the Windows 3 + Ami Pro environment, I can’t find them in the optical drive (The optical drive can’t be read, I get that error when I attempt to open it). I’ve tried with just one file, a folder of files and can’t locate them anywhere in my environment.
Are you able to reproduce the issue or did it happen once? What steps can you take to repeat the issue? What did you expect to occur and what was the actual outcome? I reproduced it several times. I can repeat the issue by running the environment with or without Ami Pro installed (I can’t open the optical/D drive). I expected to be able to open the D drive and see the content. (I feel like in prior projects we found them in the SB16 drive but I think that was because we had to bundle the content with the software or the environment itself? I can’t remember.)
Urgency: If possible, please give an indication of how urgently the issue needs to be addressed - is there a timeline or deadline (e.g. upcoming demo, researcher request, etc.) that EaaSI support staff should be aware of? This is time-limited to the Hosted Pilot project. We can work with other assets but it is modestly urgent re: Hosted Pilot project, not immediately urgent. If this is a problem that occurs across environments, it would definitely increase in urgency 
.
Hi @monique_lassere, I’m so sorry for missing this post until now - I can see/confirm the problem you’re having. I’ve also worked my way up the chain and the issue seems to persist in our MS-DOS 6.22 environments (which, the Windows 3.0 ones are derivatives of), so this is a bigger problem, as it will block mounting either ISO or Files-type Content and Software resources. I will investigate further and check back here with a fix or work-around ASAP.
Hi again @monique_lassere, there were a couple issues here but there was a fix and a work-around that should get you going again:
- The CD-ROM driver used in many of the published MS-DOS (and Windows 3.0) environments is apparently buggy, so indeed the OS will sometimes display a “cannot read the D: drive” error when an environment is started with an ISO or Files-type resource mounted. This bug is on the emulated/guest OS side (unfortunately, so it will be more difficult to fix…) but there is a quick work-around, which is:
- using the “Change Resource Media” button in the running session, swap to the “0 - empty” drive
- immediately click/swap back in the same menu to the ISO file you want (probably “1 - _import.iso” in this case, since this is Files-type Content)
- refresh or try again to access the D: drive; the ISO should now properly mount for you to interact with
I will do my best to see if we can configure a better CD-ROM driver and fix existing environments as quickly as possible…
- The specific “Windows 3.0 + AmiPro 1.2” published environment you were using seemed to have a floppy disk image permanently bound in its drive configuration metadata (but inaccessible), which caused a further issue with mounting new resources and broke even the work-around I just described above. That I was able to fix - there should now be a published environment visible labelled “Windows 3.0 + AmiPro 1.2 FIXED” - and again, I will investigate further to pin down how/why that happened for the future, but I can at least fix it on the fly if it happens again.
Please let me know if, following the work-around in my first bullet point, you can access your .SAM file now!
1 Like
Hi, there, Ethan!!
-
That workaround did work: I was able to access the file in the D: drive (though Ami said it wasn’t an Ami document and refused to open it, but that’s another issue!). Thank you!
-
Weird… if you find out why, can you let me know? I’m curious if it’s something I did, though I can’t think of what it would be. Thank you so much!
Thank you again for providing that work around. I’m going to continue trying to access some Ami files in there.
1 Like