Warning! HFS+ support in Linux is still beta

[teroyk]

Somebody might noticed that nowadays Linux has support for Mac OS 9 filesystem HFS+,
but it is still beta stage. I have noticed that sometimes big files over 4 GB not copied that they should.
They looks like ok size, but when you check MD5 or other checksum it is wrong and if you try
fix disk with OSX Disk utility it finds errors those files and fixin them to smaller size.

So you should calculate checksum (command in linux is md5sum, not md5 like in OSX) and then copy.
Remember there is some Mac OS 9 md5-tools, but what actually works with big files?

[OS923]

Mine works with unlimited file size. See https://macintoshgarden.org/apps/os-923

[OS923]

My bad. It's limited to 2 GB.

[IIO]

interesting; the block size file size limit between HFS and HFS extended is the main difference from a user perspective, but the "HFS+ for linux" all dont do it?

btw. can you use HFS+ with OS 7.0?

[Jubadub]

btw. can you use HFS+ with OS 7.0?

To my knowledge, Mac OS versions that predate 8.1 cannot write or access or even see files in an HFS+ partition. In fact, that is the "only real reason" that 68k Mac users might want to stick with 8.1 instead of 7.5.5. Although even 8.1, on 68k, can't boot from an HFS+ partition. (8.1 PowerPC can.)

On an offtopic side-note, the reason I bring up 7.5.5 instead of 7.6, 7.6.1, 8.0 and 8.1 is because it has full MFS support and can still be run in 24-bit mode on compatible machines (good for even greater software compatibility). For full MFS support, 7.6 could still be considered, but on top of lacking 24-bit mode, it accidentally rolls back a bugfix. 7.6.1 addresses the accidental rollback, but then also chops off some of the MFS support. Either 8.0 or 8.1 removed MFS support fully.

[teroyk]

My bad. It's limited to 2 GB.

What makes that 2 GB limit in your software? Signed 32-bit variable?

[OS923]

Most of my programs read the files entirely into memory, which means that the size is limited to the maximum memory partition for a program which is about 1 GB. Because I had some files that were larger I wrote several checksum calculators that read the files in blocks of 16 K. I thought that I had done this with HFS+ but I checked it and it’s HFS. But no worries, my new framework uses HFS+. The new C++ programs will support large files.

[OS923]

My new programs calculate CRCs and checksums on data forks that may be larger than 2 GB:
- Calc CRC32 (30 MB/s) (based on the standard algorithm).
- Calc MD5 (30 MB/s) (based on the code of MetroWerks).
- Calc Whirlpool (6.7 MB/s) (based on the code of Vincent Rijmen).
- Calc Zip32 (30 MB/s) (based on the standard algorithm).
This is about 50% faster than my old programs that were limited to 2 GB.
They were tested on a MDD 1.25 GHz DP with standard 128 GB HD.

[OS923]

It's better than I thought. It calculates a CRC on a 600 MB file in 20 seconds, while the old program needs 35 seconds.

The new version supports suspend and resume.

[OS923]

!!! BUG !!!

Calc Zip32 calculates a CRC32 and Calc CRC32 calculates a Zip32. They both do the same calculation, but CRC32 will at the end xor the result with 0xFFFFFFFF. When I moved the calculation to a common base class, I moved the xor too, thus Calc Zip32 did the xor once, and Calc CRC32 did the xor twice, and this caused the bug. This is now corrected.

[OS923]

I eliminated unnecessary copies. The new version is 2% faster.

[OS923]

I improved it with faster drawing.