|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Is this expected behavior in Basilisk II? (Read 28078 times) | ||||||||||
|
cballero
1024 MB  Posts: 1179 System 7, today and forever 
|
on: December 06, 2023, 20:59
I was installing FM 4.1 for a personal project and I was running out of room because the FM install image was inside of another image  In a desperate move, I copied that inner install image out to my shared 'Unix' folder and then on a whim decided to try to mount it, knowing (well, expecting) it to give me an error message (as I recall seeing it happen before) except, in this particular case Disk Copy actually mounted it without issue!  Again, what I expected to happen didn't happen, making me wonder if this can be replicated? Who knows, maybe the trick is to put an image inside of another one, mount it, copy it out to the shared folder on the host OS, and then it would actually mount externally just fine?  I've restarted Basilisk II due to an unrelated glitch, but the image FMP 4.1 image mounted again. Was I mistaken when I recalled that mounting .img files from the host shared folder didn't work? For reference, it's Mac OS 8.1 running within the Play Store Android version of Basilisk II running on Chrome OS 119.0.6045.192, 64-bit (I assume it's the latest version atm) and the Android version is 9. |
||||||||||
|
68040
|
512 MB Posts: 950 68k - thy kingdom come, thy will be done !
Reply #1 on: December 06, 2023, 21:37
|
Stop-what-you-are-doing-right-now-and-step-back-from-your-machine!! I mean it, your data is at stake! Basilisk II uses a crude mix of resource and file info files (stored inside the .rsrc & .finf dirs) in combination with a Desktop DB to mimic the behavior of a native MacOS disk for this Unix/Windoze directory. The real life mileage you get from this is completely unpredictable - and there are no intentions to change that. Because that Unix dir is under-no-circumstances meant to store life data. Whatever you do there might work in once instances and in the next it blows up right in your face. There are no consistency checks for said resource and file info chunks and the buffering on the external dir is unpredictable at best. File lock mechanism don't work there, because that filesystem is outside of B-II's control. And the emulator won't notice any changes on OpSys level until you perform a refresh on the directory tree. And so on and so on. I myself was once foolish enough to use the Unix dir to store many megabytes of files, only to lose most of them once those hidden sub-dirs got corrupted. Please, spare yourself that agony.
Last Edit: December 06, 2023, 21:54 by 68040
|
cballero
|
1024 MB Posts: 1179 System 7, today and forever
Reply #2 on: December 06, 2023, 21:49
|
Thanks for that warning breakdown, 68040!! I completely get you on that and thankfully my install is all done now, but it's a good warning to me and anyone else who's trying to get more mileage from their storage; I'll just use bigger disk images and mount those within the Basilisk II interface then! I knew something wasn't right somewhere, I just didn't know exactly where! 
|
|
Pages: [1]
|
| |||
|
© 2021 System7Today.com. |
