Error accessing hardfile

girv · 23 May 2020, 16:28

I've imaged an old 4.3Gb A1200 hard drive using dd and I'm trying to mount it in FS-UAE. I've done this with other, larger drives with no issues, but this one is giving me the error below.

FSUAE is set to an A1200+030+ a lot of fastram. It's a SFS/01 partition, and there are three other such partitions on the image that work fine. I've updated the RDB and the boot OS (ClassicWB on OS 3.9) to the latest SFS off Aminet, and all the partitions look fine in HDToolbox.

I ran RDBRecov and it found the GIRV3 partition with no issues.

Weirdly(?) SFSSalv doesn't run on this setup but just quits with "Unknown Command".

Any ideas?

thomas · 24 May 2020, 09:28

I guess it tries to read beyond the end of the image. How big is the image exactly in bytes?

SFSsalv does not run in any environment. I never got it to work anywhere.

Can you run this and post it's output here: http://thomas-rapp.homepage.t-online.../hddreport.lha

girv · 24 May 2020, 12:44

The image is 4238082048 bytes.

HDDReport output is here: pastebin.com

The GIRV3 partition is the one that's giving the error.

I was hoping perhaps SFSSalv might be able to recover deleted files from the GIRV2 partition (there's nothing in the SFS deleted files dir), but literally grepping the .hdf for telltale strings gave me nothing so perhaps it's a lost cause anyway.

thomas · 24 May 2020, 15:03

Yes, as expected, the image is too small.

The offset given in the message is 4294816768 (2^32 - 150528), that's behind the end of the image.

The hdd report says this, too:

Code:

    last readable block using CMD_READ            8277503 (4042 MB)
    last block contained in a DOS device          8388314 (4096 MB)

I had a similar phenomenon with a 40GB Seagate drive from my AmigaOne. After connecting it to a PC mainboard it reported itself smaller than before. I found that with Seatools I can restore the original size. However, the former lost space has been reset so that the last partition still is not readable even though its end is accessible again.

Besides the strange behaviour of the HDD I also blame SFS for its bad support and low error tolerance.

girv · 24 May 2020, 16:05

Hmm, OK. Thanks! The dump was made via a USB-SCSI adapter on a MacBook, but I didn't check the size it reported. I can't check again now as the PSU I was using went pop(!) and it will be some weeks before I get a replacement :/

How strange it worked on the A1200.

girv · 25 May 2020, 00:18

I got the actual drive mounted in WinUAE. It reported 4095Mb size, but making a hardfile from WinUAE stopped before this size. However, it boots to AmigaOS without issue and I am able to copy the files from the problem partition to a fresh hardfile within WinUAE.

I'd still like to get a full image of the disk though, if that's even possible. Can you recommend an OS3 program that could dump an image of the whole drive (an image that could be used directly as a hardfile)? I see a very old 'dd.lzh' on Aminet that I'll give a try once the file copies finish, but I'm open to suggestions.

thomas · 25 May 2020, 12:11

TSGUI can do it: http://thomas-rapp.homepage.t-online...oads/tsgui.lha

But I doubt that WinUAE will allow you to read to the end of the drive. It probably uses the came code to access the drive from AmigaOS as it uses to make a HDF of it from the GUI.

You'll probably have to run TSGUI on your A1200 and store the image file on some external storage.

girv · 26 May 2020, 09:33

FWIW, I made an image with TSGUI on WinUAE and it turned out at 4294817280 bytes - 150016 bytes short of 4096Mb and about 55Mb larger than 'dd' made on my MacBook. WinUAE was able to boot from this with no issues.

Thanks for the help

Hewitson · 27 May 2020, 15:13

Why would the image created with TSGUI have differed from the dd image?

girv · 27 May 2020, 15:24

dd was used to copy the whole disk (dd if=/dev/disk5 of=dump.hdf) until it ran out of sectors. I've no real idea why it would have a different size to what the Amiga environment produced, sorry.

dd was run on a Mac, TSGUI on WinUAE on Windows. Maybe there was something in macOS that made the difference.

Hewitson · 27 May 2020, 15:56

Quote:

Originally Posted by girv

dd was used to copy the whole disk (dd if=/dev/disk5 of=dump.hdf) until it ran out of sectors. I've no real idea why it would have a different size to what the Amiga environment produced, sorry.

dd was run on a Mac, TSGUI on WinUAE on Windows. Maybe there was something in macOS that made the difference.

I wonder if /dev/rdisk5 would have produced a different result?

girv · 27 May 2020, 16:09

Quote:

Originally Posted by Hewitson

I wonder if /dev/rdisk5 would have produced a different result?

Perhaps. I thought of that, but only after I'd packed everything away

23 May 2020, 16:28	#1
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	Error accessing hardfile I've imaged an old 4.3Gb A1200 hard drive using dd and I'm trying to mount it in FS-UAE. I've done this with other, larger drives with no issues, but this one is giving me the error below. FSUAE is set to an A1200+030+ a lot of fastram. It's a SFS/01 partition, and there are three other such partitions on the image that work fine. I've updated the RDB and the boot OS (ClassicWB on OS 3.9) to the latest SFS off Aminet, and all the partitions look fine in HDToolbox. I ran RDBRecov and it found the GIRV3 partition with no issues. Weirdly(?) SFSSalv doesn't run on this setup but just quits with "Unknown Command". Any ideas?

24 May 2020, 15:03	#4
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 6,985	Yes, as expected, the image is too small. The offset given in the message is 4294816768 (2^32 - 150528), that's behind the end of the image. The hdd report says this, too: Code: last readable block using CMD_READ 8277503 (4042 MB) last block contained in a DOS device 8388314 (4096 MB) I had a similar phenomenon with a 40GB Seagate drive from my AmigaOne. After connecting it to a PC mainboard it reported itself smaller than before. I found that with Seatools I can restore the original size. However, the former lost space has been reset so that the last partition still is not readable even though its end is accessible again. Besides the strange behaviour of the HDD I also blame SFS for its bad support and low error tolerance.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Simulated Hardfile-Error?	sigma63	support.WinUAE	24	17 March 2016 09:38
Accessing my CF HDD?	commodoresales	New to Emulation or Amiga scene	12	24 March 2012 11:47
Floppy accessing	kixs	support.Hardware	9	12 October 2011 00:35
Problem accessing HD	ruffian	support.Hardware	6	10 November 2009 14:01
Error Accessing ENVARC:sys ...	LAJ	support.Apps	2	19 December 2004 14:22

24 May 2020, 09:28	#2
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 6,985	I guess it tries to read beyond the end of the image. How big is the image exactly in bytes? SFSsalv does not run in any environment. I never got it to work anywhere. Can you run this and post it's output here: http://thomas-rapp.homepage.t-online.../hddreport.lha

24 May 2020, 12:44	#3
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	The image is 4238082048 bytes. HDDReport output is here: pastebin.com The GIRV3 partition is the one that's giving the error. I was hoping perhaps SFSSalv might be able to recover deleted files from the GIRV2 partition (there's nothing in the SFS deleted files dir), but literally grepping the .hdf for telltale strings gave me nothing so perhaps it's a lost cause anyway.

24 May 2020, 16:05	#5
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	Hmm, OK. Thanks! The dump was made via a USB-SCSI adapter on a MacBook, but I didn't check the size it reported. I can't check again now as the PSU I was using went pop(!) and it will be some weeks before I get a replacement :/ How strange it worked on the A1200.

25 May 2020, 00:18	#6
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	I got the actual drive mounted in WinUAE. It reported 4095Mb size, but making a hardfile from WinUAE stopped before this size. However, it boots to AmigaOS without issue and I am able to copy the files from the problem partition to a fresh hardfile within WinUAE. I'd still like to get a full image of the disk though, if that's even possible. Can you recommend an OS3 program that could dump an image of the whole drive (an image that could be used directly as a hardfile)? I see a very old 'dd.lzh' on Aminet that I'll give a try once the file copies finish, but I'm open to suggestions.

25 May 2020, 12:11	#7
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 6,985	TSGUI can do it: http://thomas-rapp.homepage.t-online...oads/tsgui.lha But I doubt that WinUAE will allow you to read to the end of the drive. It probably uses the came code to access the drive from AmigaOS as it uses to make a HDF of it from the GUI. You'll probably have to run TSGUI on your A1200 and store the image file on some external storage.

26 May 2020, 09:33	#8
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	FWIW, I made an image with TSGUI on WinUAE and it turned out at 4294817280 bytes - 150016 bytes short of 4096Mb and about 55Mb larger than 'dd' made on my MacBook. WinUAE was able to boot from this with no issues. Thanks for the help

27 May 2020, 15:13	#9
Hewitson Registered User Join Date: Feb 2007 Location: Melbourne, Australia Age: 41 Posts: 3,772	Why would the image created with TSGUI have differed from the dd image?

27 May 2020, 15:24	#10
girv Mostly Harmless Join Date: Aug 2004 Location: Northern Ireland Posts: 1,109	dd was used to copy the whole disk (dd if=/dev/disk5 of=dump.hdf) until it ran out of sectors. I've no real idea why it would have a different size to what the Amiga environment produced, sorry. dd was run on a Mac, TSGUI on WinUAE on Windows. Maybe there was something in macOS that made the difference.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)