Newbie question re Hard Drives and WB installs

[Pat the Cat]

Originally Posted by idrougge

The difference between my solutions and your solution is that yours is purely theoretical.

Every piece of transmitted data received is theoretically information. However, it should be tested for validity and value to applying this to find working solutions. That is what is important.

(To self - there is a search option. Use it. But do not always believe everything from one source or poster.)

Always question, but do not question to the extent of ignoring different solutions, because usually there is more than one way of doing things.

[idrougge]

Your solution is not a solution since it does not work. It's the opposite of information – desinformation.

[fgh]

Just a few comments...

A second DH0: becomes DH0_0: on real hardware as well.

If you are booting a system hardcoded to use dh0 (cwb or otherwise) from a partition that is renamed to dh0_0, you can boot without startup-sequence to avoid errors.
For larger drives that rely on setpatch or other scsi.device patch during boot, I'd simply rename the new partition temporarily instead (in hdtoolbox)

If you simply copy files in shell, use the all and clone arguments as mentioned.
Copying large partitions in Dopus can fail due to running out of RAM.
I prefer to store backups of system installs in lha archives in case I screw something up. (lha a -aezrx source dest) (uncompressed, quicker)

A CF card in a PCMCIA adapter (compactflash.device) can have any file system, not just FAT.
Booting from PCMCIA was not unheard of in the nineties, with products like archos overdrive (IDE HDD over pcmcia) They used a tiny cco: drive or something similar to autoboot.

As idrougge said, I don't think cf/sd cards work at all with cc0:, hence the reason for compactflash.device. (which by the way is romable, and apparently you can even boot with fat95, check the docs )

Edit: So for the OP, if it was not already clear: Yes you can simply copy the files.
And I'd use PFSaio as the file system.

[appiah4]

Thanks a lot fgh. Never meant for this to get as hot as it did but I guess it can serve as a pointer ro others. Will copy all clone the classicwb drive onto a cf partition with pfsaio. Cheers!

[appiah4]

I've tried this last night, after managing to get a hold of an oldish 2GB CF card (Sandisk Extreme III). It took me a couple of hours because of two weird quirks; I hope my example will make someone's life much easier in the future:

1. Do NOT plug in your USB CF Reader to a USB Hub, a USB port on your monitor (effectively a USB Hub) or a front panel USB port. This has resulted in several botched attempts. For whatever reason PSF3 kept giving me ablock index errors and the like in the middle of operation until I plugged the card reader directly into a mainboard USB port.
2. Do NOT try to copy over your WHDLoad collection from one hard drive to the other with Dopus. No matter how many times I tried, it caused PSF3 corruption. Use the COPY DH0: DH1: ALL CLONE command instead.

It was smooth sailing after these problems were dealt with and I can boot from and run the system from CF in WinUAE. Now just waiting for the ACA500plus so I can try it on a real Amiga 500.

[Toni Wilen]

Originally Posted by appiah4

1. Do NOT plug in your USB CF Reader to a USB Hub, a USB port on your monitor (effectively a USB Hub) or a front panel USB port. This has resulted in several botched attempts. For whatever reason PSF3 kept giving me ablock index errors and the like in the middle of operation until I plugged the card reader directly into a mainboard USB port.

This is hardware problem (not all reader/hub combinations work), it does not have anything to do with software.

2. Do NOT try to copy over your WHDLoad collection from one hard drive to the other with Dopus. No matter how many times I tried, it caused PSF3 corruption. Use the COPY DH0: DH1: ALL CLONE command instead.

Which PFS3 version? There was one related bug fix in pfs3aio that isn't in official pfs3 when using "large" partitions (as in >5G or so)

If it is pfs3aio, I want more information There is one mysterious problem that no one knows where it comes from and it usually triggers when copying huge amounts of files, this probably has been in pfs3 for a very long time.

(size of partition, dopus version, how many files copied etc)

[appiah4]

Originally Posted by Toni Wilen

This is hardware problem (not all reader/hub combinations work), it does not have anything to do with software.

This is very likely an issue with not enough power being supplied to the USB ports other than the mainboard - my impression was that the card reader disconnected and reconnected during the read/write operation as the power draw increased as the ablock index etc. errors coincided with Wİndows prompting me with the option of formatting my CF card out of the blue.

Originally Posted by Toni Wilen

Which PFS3 version? There was one related bug fix in pfs3aio that isn't in official pfs3 when using "large" partitions (as in >5G or so)

If it is pfs3aio, I want more information There is one mysterious problem that no one knows where it comes from and it usually triggers when copying huge amounts of files, this probably has been in pfs3 for a very long time.

(size of partition, dopus version, how many files copied etc)

It is indeed PFS3 AIO v18 Rev5; it happened when copying over 486,371,248 bytes of WHDLOAD data in the form of 14,826 Files and 717 Folders from a folder on a GPT partition mounted as UAE-IDE on DH1 in WinUAE 3.4.0 to a 1.79GB PFS3AIO 18.5 FS hard drive partition on a Sandisk Extreme III 2GB CF card mounted as UAE-IDE on DH3.

I experienced data corruption while copying files with Dopus (as supplied in ClassicWB, i.e. Directory Opus v4.16, DOpus Library v22.18, Compile date Jun 23 2001, Compile time 20:19:21, Port/screen name DOPUS.1) in this setup continuously in the form of "wrong index block id" or "wrong ablock id" which resulted in locked partitions that had to be manually unlocked in shell (which did not fix the FS corruption) and reformatted. Eventually, the files copied over fine with a shell command COPY DH1: DH3: ALL CLONE, however I do not know if this was due to a) sheer luck, b) Dopus causing the corruption, c) using a 68040 CPU with FPU in emulation instead of an 68000 running at 14MHz to emulate the ACA500Plus. Whichever it was, it finally worked.

Cheers.

[Toni Wilen]

Finally new clue: it can happen with small partitions too. Which dopus version?

[appiah4]

Originally Posted by Toni Wilen

Finally new clue: it can happen with small partitions too. Which dopus version?

I used Dopus as supplied in ClassicWB (Directory Opus v4.16, DOpus Library v22.18, Compile date Jun 23 2001, Compile time 20:19:21, Port/screen name DOPUS.1)

Hope it helps you!

[daxb]

You could try a newer version of DOpus4. There is at least 4.17 and recently I read about 4.18. Just to be sure that DOpus4 is the causer or not. Maybe it is also worth to try a verify copy.

[Toni Wilen]

No no no. The point is to find the problem, not to hide it

Filesystem operations can't corrupt filesystem, it probably is related to dopus usage pattern (size of copy buffer, how it modifies flags/comments etc..) that triggers some rare bug in some filesystem operation.

[appiah4]

Originally Posted by Toni Wilen

No no no. The point is to find the problem, not to hide it

Filesystem operations can't corrupt filesystem, it probably is related to dopus usage pattern (size of copy buffer, how it modifies flags/comments etc..) that triggers some rare bug in some filesystem operation.

I'll have a new 4GB card in the mail soon and this will be relegated to an AUX drive. I can continue trying to replicate the issue for you in a few days, if it would help. Feel free to contact me with any questions/requests. I would be happy to do my share in hunting this bug, if there's anything more I can do, that is.

[powrslave]

If you have two mounts it will be DH1: and DH1_0: for example