SFS partition not found under WinUAE

[scholle]

Dear friends of SFS & WinUAE,

I have a major problem getting data from a backup
harddrive previously used in a now dead A4000.
Trying to revitalize my system under WinUAE, I
found that the SFS-partition, where all my important
data reside is not mounted during boot time.

The partition worked perfectly inside the A4000
with OS3.9. Now I can only use the boot partition
with FastFilesystem I had created, the data
partition is marked as "Not a DOS drive" bzw.
"Unformatiert", which means unformatted.

The harddrive is a Samsung SP4002H QU10 (as seen
in HDToolbox) with 37,3GB size. The first physical
partition on the drive is of Linux Boot type. The Amiga
boot partition is in the middle, the important data
partition is the last one and has 11,9GB.

SmartFilesystem is installed in L: and also on the
disk itself. I have version 1.230 (size 78508 bytes)
with id 0x53465300.

Is there any chance that I can access to the data?


Best regards,

Scholle

[Thomas]

Please get the Check4GB archive from Aminet, run the program CheckHD and post the output here.

Bye,
Thomas

[scholle]

Getting the archive from Aminet on the PC side is no problem, but how can I put it on the Amiga side. I'm not really familiar with WinUAE. Is it correct that I can use an .adf File as Amiga-Disk? How can I compile an ADF on the PC side? With WinUAE I can only create empty ADF files, right? How can I fill them with data?

Thanks,

Stefan

[Damion]

To share files, simply start WinUAE, click "Hard Drives", and then "Add Directory". You can share files now between any directory you choose, even while the emulator is running.

You can use an ADF as an amiga disk, but I can't recall how to create them anymore. 3.9's "unarc" program will unpack them though, IIRC.

 

[scholle]

@Thomas:

Thanks, this is what CheckHD says:

Name   Volume     Device             Unit     Size >4GB DosType  Version
RAD    RAD        vdisk.device          0  2.00 MB  no  DOS\03   45.14   ok
HD0    Bridge     uaehf.device          0  1.02 GB  yes DOS\03   45.14   ok
DF0               trackdisk.device      0   880 kB  no  DOS\00   40.1    ok
OpenDevice failed !
Add    Add        uae.device            1     0 kB  yes DOS\00           ***
HD3    Temp2      uaehf.device          0 12.08 GB  yes SFS\00   1.230   ok
HD1    Store      uaehf.device          0  8.02 GB  yes DOS\03   45.14   ok
HD2               uaehf.device          0 11.96 GB  yes SFS\00   1.230   ok
DF1               trackdisk.device      1   880 kB  no  DOS\00   40.1    ok


The data partition, which does not work correctly, is HD2:

For me it looks okay...


Best regards,

Scholle

[Thomas]

Wasn't SFS V1.230 the one which had problems and it was recommended to fallback to 1.227 ?

Does SFSSalv see files on the partition ?

Bye,
Thomas

[tomekm]

i`ve had the same problem even with smaller drives. I connected my 4g caviar to pc with system partition as pfs3 and work as sfs and all i could do was to copy files using sfssalv. It worked, fortunately... The problem may be on the winuae`s side: it simply may have problems adressing the drive size, it may assign different drive geometry, thus, give the drive some fewer blocks it should. I think if I created a partition smaller by some megs, it would become visible. I have no way to check it, because i`m out of harddrives...

[Thomas]

I doubt this. First of all I successfully used a 20gig HDD with all partitions working. Secondly the original drive geometry does not matter, AmigaDOS uses what is stored in the RDB.

The problem with SFS is more likely as I remember people complaining about disappearing partitions when upgrading to the latest SFS version.

Bye,
Thomas

[tomekm]

well, i had mentioned problem with 1,2gb drive, too. I know OS uses rdb, but what if num.of.blocks in rdb doesn`t match num.of.blocks given by uaehf.device? this may lead to problems if uaehf.device returns less blocks than the drive actually has. and the dissappearing partitions were documented in docs for new sfs. It was said that this version in incopatible with older ones.

[scholle]

AFAIRC there was a newer version than 1.230 and it was recommended to fallback to the latter. I usually wait some weeks before using a new version of SFS, also reading the SFS mailinglist, wether there are problems. However, I cannot check now, as all the email is on the data partition.

But maybe I've found the cause of trouble:

After SETPATCH there are two lines in my startup-seqeunce:

C:LoadModule Libs:mathieeesingbas.library Libs:mathffp.library NOREBOOT
C:loadmodule LIBS:mathieeedoubbas.library NOREBOOT

These are faster version of the math-libs, which I had registered for speed issues on my A4000. AFAIRC these were 060 versions. It looks like they are not really loaded on startup, as I get the following even for my boot partition:

4> sfscheck hd0:

Can't open mathieeedoubbas.library
Required library missing

So I'll reinstall the original libraries and see wether it works...

Best regards,

Scholle

[scholle]

Ok, I've installed the original mathieeedoubbas.library, I couldn't find mathieeesingbas.library or mathffp.library on my OS3.9 CD...

SFSCheck runs cleanly now, here is the output for HD2:

4> sfscheck hd2:
Partition start offset : 0x00000006:55C20000   End offset    : 0x00000009:53C94000
Surfaces               : 8                     Blocks/Track  : 252
Bytes/Block            : 1024                  Sectors/Block : 2
Total blocks           : 12550608              Size          : 0,0MB/0,0MB (0%)
Device interface       : NSD (64-bit)          Version       : 1.230
Device buffers         : 80                    Device caches : 8x8192 (65536 bytes) [CPB]
Check buffers          : 128x8192 (1048576 bytes) [CPB]

Checking RootBlocks
Checksum failure.
...damaged


Unfortunately SFSSalv still refuses to work. I've tried version 0.17 and get "Unknown command" and version 0.16, resulting in "File is not executable". What other files do SFSSalv rely on? Any hints?

TIA,

Scholle