Print

[IIO]

is there really nothing like split & concat for OS9?

i need to split a DVD image into 3 pieces and would like to avoid making zip-parts.

[Mat]

Did you give "Split & Join" a try already?

[IIO]

i did not know that system 6 app until now! it seems to do the same and it works fine in 922.

but, surprise surprise, it wont open files that big.

splitville and splitit! same, 2gb limit.

i could build one with max, but suppose that spooling a file using blocks of 32 bits will takes ages.

[refinery]

Isn't there a 2gb file size limit in OS9?

[IIO]

the file size limit is 2TB

[Jubadub]

Isn't there a 2gb file size limit in OS9?

Nope, unless if your disk is HFS and not HFS+, case in which I think there is. We wouldn't be able to use even DVD images otherwise, which I do and mount all the time for all sorts of stuff, like booting off mounted DVD images in Virtual PC 6.

And beware AFP drives: transferring files via AFP truncates data to 2GB, so use FTP or other protocols for file transfer between Macs for transfers above 2GB.

I had a single file backup of an entire disk of roughly 180GB long ago, OS 9 mounted that just fine, too. Nowdays I keep backups limited to 23GBs (and not as a single image file), though, so data fits in Blu-Rays discs, which work just fine in OS 9 as well (if you insert the disc only after the OS booted, that is).

[IIO]

i do the same (limiting archives of everything to max of 23gb), but i usually make 4 gb ("DVD") image files so that no more than 5-6 files are burnt to BD - otherwise it takes ages to mount the BD media later.

the split job is required for hotline, where the original transportation protocol already seems to have that filesize limit.

it would be lovely if we could use something directly on OS9, which is particulary important for the people who download.
it is not that many files where an OS9 software (-component) actually comes as DVD or otherwise exceeds 2.13gb, but it exists, and i would hate breaking the new law i made that files shall not be stuffed or zipped with SITD (which of course would be a working solution otherwise.)

[robespierre]

Any application written before HFS+ won't be able to seek in a file over 2GB (the _GetFPos and _SetFPos traps use 32-bit byte pointers). This would also be the reason for the AFP problem.
This was an issue for most operating systems—if they were originally written before the 1990s—including Unix. New 64-bit ABIs needed to be added to allow for longer files: lseek64() on Unix, for example.
A counterexample: BeOS had 64-bit offsets from its beginning.

[IIO]

yeah that´s what i would suspect. it is a shame that all of these otherwise working utilities are from system 7 times or older.