Login  •  Register


The time is now: Tue Dec 18, 2018 9:16 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 1 of 1 [ 20 posts ]
Print view Previous topic  |  Next topic
Author Message
PostPosted: Tue Nov 06, 2018 5:35 pm 
Offline
Inquisitive Elf

Joined: Mon Sep 16, 2013 9:47 pm
Posts: 27
I have just tried out the newest version (36.04) of Mini vMac and am having problems. I am on macOS 10.14.1, and am using the x86-64 Macintosh II variation of Mini vMac for OS X that I downloaded from www.gryphel.com.

My problem is that I can't import any files into Mini vMac 36.04. I've tried two methods: 1) importfl, and 2) HFVExplorer (which I run via wine) plus an hfv or dsk image. In both cases, I get the message:

'You cannot move "filename" to the disk "MacHD", because the disk is locked.'

Note: I am able to export files using exportf1.

I have an earlier version of mini vMac (3.3.2), also the x86-64 Macintosh II variation, which does allow me to import files using either of the methods above. (However, I want to use the newer version because the sound is much better.)

For both versions of Mini vMac, I am using the same DISK1.DSK and DISK2.DSK, which has System 7.5.5 on it.

What am I doing wrong?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 06, 2018 7:13 pm 
Offline
Forum All-Star

Joined: Wed Nov 11, 2009 5:47 pm
Posts: 1162
Location: Germany
Not an answer, but why not put all needed files into a NDIF image created by Basilisk II or SheepShaver?
I´m doing just that all the time, but I have SheepShaver on all my rigs.
Therefore moving files is just on the fly. :)


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 06, 2018 7:28 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
First thing to check: is the disk locked? Either on your host OS X system or within Mini vMac?

Second thing to check: is the disk already opened in some other context? Eg: if you've got it loaded in Mini vMac, it won't be accessible to HFVExplorer.

Also: have you tried creating a new disk image that you know is readable and writeable and using Importfl to import to that disk?

Lastly, there's a nifty little utility linked somewhere in these forums: http://www.charlessoft.com/HFS_Disk_Maker.zip -- it lets you select a folder of items on your host and create an NDIF disk image of it. You can then drag this over Mini vMac's window to mount it.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 06, 2018 8:11 pm 
Offline
Inquisitive Elf

Joined: Mon Sep 16, 2013 9:47 pm
Posts: 27
Thanks -- I'll try to respond to the best of my ability:

1) I checked, and no disks are locked

2) No, no disks were open anywhere else

3) I know that the disk I used with HPVExplorer was both readable and writable, because I can use it to both import and export files to/from my earlier Mini vMac version (3.3.2) with no problem. Also, I can use Importfl with Mini vMac 3.3.2 with no problem. (and I don't know how to use Importfl to import a file to a disk -- I only know how to use it to import into Mini vMac)

4. I tried HFS Disk Maker, and although it creates a IMG file, it does so with an error:

Disk image creation failed: Error Domain=NSCocoaErrorDomain Code=4 "The file “rsrc” doesn’t exist." UserInfo={NSFilePath=/Users/dad/Desktop/test/achaos02.mid/..namedfork/rsrc, NSUnderlyingError=0x600000258510 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

The resulting IMG file is not recognized by either version of Mini vMac that I have.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 07, 2018 2:19 pm 
Offline
Nice Guy
User avatar

Joined: Sat Nov 17, 2007 6:46 pm
Posts: 105
Another thing to check: does it work to use importfl to import to a fresh blank disk image, from the Blanks archive. That would tell whether there is an issue with your MacHD disk, or a more general problem.

Also, have you tried recently using importfl with Mini vMac 3.3.2, to make sure that it still works? Otherwise, a problem with your MacHD is more likely.

So, are you saying the when booting from MacHD in Mini vMac, there is not a lock icon in the Finder window?

Also, who is giving that error message? That is not an error message that importfl can give. Or do you just mean that importfl gave a similar message with different wording?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 07, 2018 3:43 pm 
Offline
Inquisitive Elf

Joined: Mon Sep 16, 2013 9:47 pm
Posts: 27
I'm not very "skilled in the art," but here are my answers:

1) So I downloaded the blank disk images, but unfortunately I don't know how to use Importfl to import a file straight to a disk image -- I only know how to use it to import into Mini vMac.

2) Yes, importfl works fine with Mini vMac 3.3.2

3) Aha, yes, there is a lock icon in the Finder window in Mini vMac 36.04. I have no idea how to get rid of it, though. Looking at DISK1.DSK and DISK2.DSK in macOS, they are not locked.

4) That error message wasn't from importfl. It was from HFS Disk Maker, which I was using in macOS to try to create a disk image of a folder, as per adespoton's reply above.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 07, 2018 8:08 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
I think there's been a bit of confusion here; I'll try to talk to your points:

1) Drag the blank disk image over Mini vMac: it will mount on the Mini vMac desktop. Then run ImportFL and attempt to save the file to that disk. It won't save to your other disk, because that disk is locked.

2) It sounds like the issue is that either you're using different disks then you were with 3.3.2, or something has caused them to get locked under 36.04.

3) If they're not locked in macOS, get info on them in Mini vMac and see if you can unlock them there. It's possible that the version of Mini vMac you are using auto-locks disk images with the original NDIF headers (it's a compile-time feature) and your copy of 3.3.2 didn't. The blank disks referenced in this thread will mount read-write.

4) Paul is referencing your original error: "'You cannot move "filename" to the disk "MacHD", because the disk is locked.'" The main error with HFS Diskmaker is expected; the resource fork error is not; I should double check that Mojave's increased security hasn't prevented HFS Diskmaker from accessing named forks.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 07, 2018 11:21 pm 
Offline
Inquisitive Elf

Joined: Mon Sep 16, 2013 9:47 pm
Posts: 27
1) Ah, OK, that makes sense. So yes, I discovered that I am able to import a file onto an 800K disk mounted in Mini vMac 36.04 using Importfl.

2) and 3) I don't know how to get info on and/or unlock a disk within Mini vMac (I've gotten into this thing with old Mac OSes only pretty recently), but yes, the Finder in Mini vMac 36.04 does show a lock, so I'd like to know how to get rid of that.

Edit: And one more piece of information -- the same DISK1.DSK and DISK2.DSK that work fine in 3.3.2 show the Finder lock icon in 36.04.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 09, 2018 12:09 pm 
Offline
Nice Guy
User avatar

Joined: Sat Nov 17, 2007 6:46 pm
Posts: 105
It does sound like this could be a Disk Copy 4.2 image, which by default is read only in Mini vMac. Though it became read only in Mini vMac 3.2, so it should be the same in your 3.3.2, unless it is a variation.

You can test this by specifying -sony-sum 1 -sony-tag 1 in the Advanced Variations Service, to enable write support for Disk Copy 4.2 images. (A demo version is sufficient for testing this.)

Prior to version 3.2, Mini vMac would write to Disk Copy 4.2 images, but not update the checksums, resulting in an invalid image. So they were made read only. There is code to support updating the checksum correctly (thanks to zydeco and Ray A. Arachelian), but it is added code that makes Mini vMac a little bit less "Mini".

It has become clear that this was the wrong choice, and this code should be enabled by default.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 09, 2018 6:59 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
Quote:
It has become clear that this was the wrong choice, and this code should be enabled by default.


Hmm... I'll have to explicitly enable it in the future then I guess... I use it to be able to load up my pristine DC42 images knowing that they won't be modified, and using the headerless images for all read/write work. I'm not sure there's a right answer here, but I agree with you that for new users, being less mini is probably better than providing an unexpected (but documented) result.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 09, 2018 8:51 pm 
Offline
Nice Guy
User avatar

Joined: Sat Nov 17, 2007 6:46 pm
Posts: 105
adespoton wrote:
I use it to be able to load up my pristine DC42 images knowing that they won't be modified


I get similar functionality by locking the disk image in the host operating system, and then keeping an md5 checksum in a separate file. (I have a script that creates or checks the checksum.)

A disadvantage may be that locking state might not always be preserved, in copy operations and archival formats. An advantage is that when an update is needed it is easy to unlock the image, modify it, lock it, and compute a new checksum.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sat Nov 10, 2018 12:02 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
Actually, what I've switched to recently is just keeping a 7z compressed copy of the image handy so I can overwrite with a known-clean one after each session. That's traditionally been for when I've been doing non-Mini vMac stuff with the image; I just have to remember to include MvM in the list for the future.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 27, 2018 11:02 pm 
Offline
Inquisitive Elf

Joined: Mon Sep 16, 2013 9:47 pm
Posts: 27
Quote:
It does sound like this could be a Disk Copy 4.2 image, which by default is read only in Mini vMac. Though it became read only in Mini vMac 3.2, so it should be the same in your 3.3.2, unless it is a variation.

You can test this by specifying -sony-sum 1 -sony-tag 1 in the Advanced Variations Service, to enable write support for Disk Copy 4.2 images. (A demo version is sufficient for testing this.)

Prior to version 3.2, Mini vMac would write to Disk Copy 4.2 images, but not update the checksums, resulting in an invalid image. So they were made read only. There is code to support updating the checksum correctly (thanks to zydeco and Ray A. Arachelian), but it is added code that makes Mini vMac a little bit less "Mini".

It has become clear that this was the wrong choice, and this code should be enabled by default.



I've finally had some time to get back to this. I followed your instructions above, creating a version of Mini vMac 36.04 identical to my earlier version, but with the addition of the -sony-sum 1 -sony-tag 1 parameters.

Unfortunately, the behavior of this newest version is the same as before: I cannot import files to the "MacHD" disk (or indeed the desktop).

Is there something else that I could try next?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 28, 2018 12:16 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
Create a new writeable MacHD disk. The desktop is just a folder on that disk, and it's not writeable, so you won't be able to write anything to it.

I just duplicated your setup with an unlocked system disk and everything worked fine for me (other than losing resource forks).


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 28, 2018 8:04 pm 
Offline
Inquisitive Elf

Joined: Mon Sep 16, 2013 9:47 pm
Posts: 27
I am quite the amateur when it comes to things like this . . . what would be the most straightforward way for me to create a writeable MacHD disk that contains all the programs I have on my current MacHD disk? Is there a way to copy the programs over, or do I have to start from the beginning?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Nov 29, 2018 3:51 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
Yes; if you open up Disk Utility under OS X, go to the Images menu and select Convert...

From the Open dialog, select the locked image and click Choose.

At the Save dialog, Select the Image Format drop-down and choose read/write.

Click Convert. then click Done. You should now have an "<image name> converted.dmg" image that should be writeable in the emulator.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Nov 29, 2018 12:14 pm 
Offline
Forum All-Star

Joined: Wed Nov 11, 2009 5:47 pm
Posts: 1162
Location: Germany
Moving files from 10.14 to 7.5 may be troublesome.
Usually you want to preserve the resource forks of your apps and data files.
Any Mac OS above 10.5 is incapable of writing HFS volumes in a simple way.

As far as I can tell, you got these options:
- OSX 10.5 Server in VMware
- SheepShaver (Basilisk II)

Lets assume SheepShaver as your solution, as it looks easier.(Same procedure for Basilisk II)
Also, lets take a Apeiron game folder from Macintoshgarden as an example.
This is the folder as seen in 10.14.1:

Image

Move the folder to SheepShaver´s shared volume. (The folder is named Classic in my case, YMMV)
Run SheepShaver.
Copy the folder to a SheepShaver Mac volume (not to the SheepShaver desktop).

Image

Run DiskCopy 6.
Navigate to the folder and select it.
Press Control-J to create a HFS image from it and select the topmost entry in the pulldown menu for read/write.

Image

The disk image is created.
Move the .img back to the shared folder.

Image

As the image is now in macOS, run MiniVMac II with your MacOS 7.5 and drag the new img onto the MiniVMac II screen.

Image

Thats it.
Sorry for some German in the screenshots.
The procedure looks more complicated that it actually is.
The man in the middle (SheepShaver or else) is needed, as Apple prevents writing HFS volumes from user land.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Nov 29, 2018 5:25 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2300
Location: Emaculation.com
Has anyone found a way to do this using qemu yet? Either via shared network or via the shared folder feature? I'm guessing the shared folder feature would strip the resource fork....


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Dec 02, 2018 2:26 pm 
Offline
Nice Guy
User avatar

Joined: Sat Nov 17, 2007 6:46 pm
Posts: 105
24bit wrote:
Moving files from 10.14 to 7.5 may be troublesome. Usually you want to preserve the resource forks of your apps and data files.


Another option is to use MiniUnZp, a simple tool for unzipping a compressed archive created by OS X. It is very unpolished, but it functions.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Dec 02, 2018 2:49 pm 
Offline
Nice Guy
User avatar

Joined: Sat Nov 17, 2007 6:46 pm
Posts: 105
archtop wrote:
what would be the most straightforward way for me to create a writeable MacHD disk that contains all the programs I have on my current MacHD disk? Is there a way to copy the programs over, or do I have to start from the beginning?


Since you have found the problem is not about Disk Copy 4.2 format, I would next suspect the issue is with code for with advisory locking, which has changed. So it would be useful to create an exact copy of only the contents of the MacHD disk image into a new file, stripping off all the meta data.

One of many ways to accomplish this is to use ImportFl to import the entire MacHD image file into a new larger blank image (that must be larger), and then immediately export it with ExportFl.

If the new copy of the image doesn't have the same problem, then that indicates the problem is not with the image data.


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 1 of 1 [ 20 posts ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group