Anyone working on PFS3 ??

[XDelusion]

Godamn Pancakes!

[Franko]

• TD_GETGEOMETRY and RDB use 32bit unsigned value to store block numbers. The maximum block number they can represent is 2^32 -1 or 4294967295.
• 3TB HDD uses block size of 512. The capacity reported is around 3 * 1000 * 1000 * 1000 * 1000 / 512 blocks or 5859375000.
• The value 5859375000 is larger than 4294967295. Thus it cannot be represented with a 32bit unsigned integer data type. Ergo TD_GETMEOMETRY or RDB cannot properly report/handle such device.

Awe Gawd... more mumbo jumbo, look Piru unlike you I'm not an andriod made of old PC parts running on a flakey version of MorphOS, so you can post all the gobbledegook or Einstein's theories on how space is really a banana and you are I don't really exist, all you want... ;)

I STILL SAY YOUR WRONG... :insane:

[Piru]

@Franko

You asked for proof and I provided it. Care to explain how my proof is incorrect?

[itix]

With the introduction in SFS of SF2 partitions the 127GB limitation

Yes but it can corrupt your data. That is at least case with the original SFS and I dont have idea about SFS2 but I dont think it was fixed. I recall Joerg said it was not fixed.

was done away with a number of years ago along with the 4GB filesize...

You can not really access files larger than 4GB in OS3. First of all file size of 4GB+ files is reported wrong (have size of 0 bytes) and applications can not seek past 4GB barrier. Some applications might be able to read those files but it is not guaranteed to work.

[itix]

Piru paying out money... aye right... and I'm the Queen of England...

No, you are the king of scotland :-)

[Franko]

Yes but it can corrupt your data. That is at least case with the original SFS and I dont have idea about SFS2 but I dont think it was fixed. I recall Joerg said it was not fixed.



You can not really access files larger than 4GB in OS3. First of all file size of 4GB+ files is reported wrong (have size of 0 bytes) and applications can not seek past 4GB barrier. Some applications might be able to read those files but it is not guaranteed to work.

Sorry mate but once again your wrong on OS3.1, 3.5 & 3.9 and SFS with SF2 partitions you can indeed read and write files even with the c: command "Copy"...

Again I assure you in all the years of using SFS I have not lost one bit of data and applications don't handle the actual data transfer (that's what the file system does)...

The only problems you will encounter are application displaying the wrong file size as most were written never expecting to take files of >4GB into account...

Heck even OS4.0 came with it's own PPC version of SFS as most apps in that are written to display the correct file and HD size...

As I've said before don't knock it till you try it...

[Franko]

@Franko

You asked for proof and I provided it. Care to explain how my proof is incorrect?

Cos I said so... simple as...

[Piru]

The only problems you will encounter are application displaying the wrong file size as most were written never expecting to take files of >4GB into account...

With AmigaOS 3.x that would be all applications. APIs in AmigaOS 3.x can only represent a 32bit number for the file size.

Only applications reading up until EOF will work properly. Any AmigaOS 3.x application that actually queries the file size first before processing that amount of data will fail. Many applications seeking in a file will fail randomly as negative return value from Seek() was commonly considered an error.

Oh I'm sorry for giving you more technically correct and factual information. You may yell "YOU'RE WRONG!" if that makes you feel any better.

[itix]

Sorry mate but once again your wrong on OS3.1, 3.5 & 3.9 and SFS with SF2 partitions you can indeed read and write files even with the c: command "Copy"...

Yes that might work indeed. It is not intended behaviour though. Just side effect of Copy command implementation.

Again I assure you in all the years of using SFS I have not lost one bit of data and applications don't handle the actual data transfer (that's what the file system does)...

You can. I dont know if it was fixed in OS3 version but there was a bug it could accidentally trash fs admin blocks. Not so annoying than crashing FFS partition though.

The only problems you will encounter are application displaying the wrong file size as most were written never expecting to take files of >4GB into account...

OS3 applications can never display file size correctly. It just isnt possible.

Heck even OS4.0 came with it's own PPC version of SFS as most apps in that are written to display the correct file and HD size...

I have never seen it so cant comment.

As I've said before don't knock it till you try it...

I have been using SFS since version 1.52 from 1998 and all my partitions are SFS still. Wrote small app for it long ago. I never had PFS.

[Franko]

With AmigaOS 3.x that would be all applications. APIs in AmigaOS 3.x can only represent a 32bit number for the file size.

Only applications reading up until EOF will work properly. Any AmigaOS 3.x application that actually queries the file size first before processing that amount of data will fail. Many applications seeking in a file will fail randomly as negative return value from Seek() was commonly considered an error.

Easy example DirWork V2.1 written in 1994/95, like I say things display the wrong file size but they copy perfectly without errors, on DirWork (or DOpus for that matter) they can easily copy an 8.3GB DVD ISO from one partition to the other without any problems...

All I know is it work for me, I'm not interested in the technical details of how it works. It does what is required without error and for me that's all that matters...

Sorry but I'm not the type who cares how many nanoseconds it takes for something to do something or how many transistors will fit on the latest CPU or why my grannies bloomers always fell down due the fact that the consistency of the elastic in them was wrong...

Me I'm just happy that things work for me on my Amiga's the way I need them to and that makes me happy & satisfied...

PS:You've made me miss getting a home delivery from the Chippy as it's now midnight, now I'm gonna have to go and cook something instead before I sit down to watch Friday Night Smack Down where at least I can relax watching something a wee bit more intelligent than all this mind numbing stuff... :furious:

[Franko]

I have been using SFS since version 1.52 from 1998 and all my partitions are SFS still. Wrote small app for it long ago. I never had PFS.

Then you should really download the last version written from the link I posted it's far better than all the earlier versions...

[Karlos]

• TD_GETGEOMETRY and RDB use 32bit unsigned value to store block numbers. The maximum block number they can represent is 2^32 -1 or 4294967295.
• 3TB HDD uses block size of 512(*). The capacity reported is around 3 * 1000 * 1000 * 1000 * 1000 / 512 blocks or 5859375000.
• The value 5859375000 is larger than 4294967295. Thus it cannot be represented with a 32bit unsigned integer data type. Ergo TD_GETMEOMETRY or RDB cannot properly report/handle such device.

You'd actually need 43 bits to represent that value (unsigned). Logarithms FTW ;)

[Franko]

You'd actually need 43 bits to represent that value (unsigned). Logarithms FTW

Don't you ruddy well start... :furious:

[Piru]

You'd actually need 43 bits to represent that value (unsigned). Logarithms FTW

Actually 33 bits. TD_GETGEOMETRY and RDB use block offsets, not byte offsets.

[Karlos]

Actually 33 bits. TD_GETGEOMETRY and RDB use block offsets, not byte offsets.

That's bizarre, I just did the exact same calculation on my CFX-9850G+ and it comes to 33 (as above), but when I did it the first time, it came to 43. I wonder what the hell I missed out? Even neglecting the /512 leaves you with 42 when rounded up

-edit-

I probably got 42 the first time and chucked on an extra bit to ensure sign couldn't be an issue.

[XDelusion]

Awe Gawd... more mumbo jumbo, look Piru unlike you I'm not an andriod made of old PC parts running on a flakey version of MorphOS, so you can post all the gobbledegook or Einstein's theories on how space is really a banana and you are I don't really exist, all you want...

I STILL SAY YOUR WRONG... :insane:

Just to clear things up a bit. I was the one who built Piru. I used parts from some old desktopp 286's and 386's I had laying around in the shed that I now use to store the children I kidnap and kill.

For the note, he does not run on a flaked out version of MorphOS as there is no such thing. Rather he is operated by a series of metallic strings which are attached to piano keys which I use to control his movement. If he seems to lack a sense of humour, that is because his humour chip was destroyed in the tragedy that was Star Trek Generations.

In relation to all the code he has written...

That again is all me. I just give my Piru bot credit in the event that someone would wish to critique my hard work... in which case all their anger will be directed at him and not me.

KarlOS on the other hand is my 2nd Generation model made mostly of Lego Machines driven by Hamsters in wheels. I is my writer's alias for all the OS4 code I'm doing.