Text 2628, 110 rader
Skriven 2011-04-06 18:20:15 av Jonathan de Boyne Pollard
Ärende: Re: formatting to FAT32
===============================
Gecko/20110303 Thunderbird/3.1.9
comp.os.os2.misc,comp.os.os2.beta,comp.os.os2.utilities,comp.os.os2.programmer.misc

UTC)
comp.os.os2.utilities:189 comp.os.os2.programmer.misc:2120
From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>

>> Well that's clearly wrong, given that it contains something that 
>> will, you tell us, make programs work for end users in this case. (-:
>>
> Do you think that end users want to know API changes of FAT32.IFS ? 
> Your end users seem to have very powerful ability. BTW, I call them 
> developers.
>
I'm sure that they'll be glad to know that you call them that, but that 
doesn't change the fact that these end users will, you tell us, benefit 
from what you did.  I have my doubts from static analysis of the code, 
and they grow stronger the more that you show that your intention is to 
break the way that OS/2 is documented as working.  But you assure us 
that the end users will benefit.

>> Do you have a binary of your not-for-end-users FAT32.IFS so that the 
>> end-users can install it and see whether it fixes the DosSetFilePtr() 
>> problem for them? I'm expecting it not to, looking at the code 
>> changes that you've made, to be honest. You don't appear to have 
>> touched anything in the ordinary, standard, "raw" path. But we'll 
>> only find out one way or the other if some of those end users 
>> actually get to test this modification.
>>
> This is just to proof that you don't know anything about IFS programming.
>
Oh dear.  You are going to come back to this in a little while and be 
embarrassed at writing it.  Asking you whether there's a binary isn't 
proof of anything about me.  And saying that people need to run and test 
what you've done is also not proof of anything about me.  But responding 
to a request for a binary, so that people can run it and test whether 
what you say is the case actually is the case in practice, with an 
insult does, alas, say something about you.

> And do you think that I committed the changeset to the public 
> repository without any checking ?
>
I think that you did worse than not testing what you did (and not 
telling anyone about it for three years).  Because what it appears you 
did was take the unit test that you and Jan van Wijk concocted all those 
years ago, and concluded that the right outcome was for it to fail 
completely, with ERROR_ACCESS_DENIED returned for everything.  So you 
did worse than not testing, if anything.  You intentionally implemented 
things with the goal of making the unit test fail in its entirety, and 
that nothing would work at all.  As I said before, this is neither 
improvement nor good.

> Hmmm... Why should OS/2 v4.5 be the standard ?
>
Because people want to be able to use FAT32.IFS on it, as OS/2 is 
designed to be used, as the OS/2 4.5 Toolkit documents it to be used, as 
Ed Iacobucci's book on OS/2 version 1.0 documents it to be used, and as 
Jan van Wijk, Allan Holm, and I have all, separately, over a period of 
years, come and told you that we use it.  Yet you refuse, tell us all 
that we don't know anything and that only you know The Truth of how 
volumes are supposed to be read and written on OS/2, and even make 
changes intended to break things further.  This is not good.

> In addition, I love the backward compatibility of OS/2.
>
Then why the Heck are you *breaking* backward compatibility?  Good 
grief.  You make changes so that the way that one reads and writes disc 
volumes, and has done since OS/2 version 1.0, now does not work at all, 
but instead returns ERROR_ACCESS_DENIED all of the time.  You aren't 
promoting backward compatibility.  You are destroying it.

> Finally, FAT32.IFS itself is a 16bits driver. So it is useless just to 
> add "L" entry points without fundamental changes of the driver model.
>
Codswallop.  Adding the "L" entrypoints provides a way for the kernel to 
call the FSD with 64-bit file position information, which in turn allows 
programs that open the volume as a file, and seek around it, read it, 
and write it as a file, to work.  Since I've given you pretty much the 
code to add FS_CHGFILEPTRL, and since that self-evidently didn't involve 
any fundamental changes to anything, it's as plain as the nose on your 
face that this "it will require fundamental changes" nonsense is just 
that: nonsense.

> Frankly, I don't think that FAT32.IFS should support "L" entry points 
> because FAT32 file system itself is a 32bit file system and the 
> current FAT32.IFS implements it enough except support for files whose 
> size is 2GB from 4GB, and for DASD IO to the volumes bigger than 2GB.
>
The files may be less than 2GiB, but the volume as a whole is.  That's 
the point.  When one is seeking around in the files one doesn't need a 
64-bit file position, but when one is seeking around in the volume as a 
whole one does.  The thing that you really don't seem to have a grasp is 
that the HPFS kludge that you're copying, and that you seem to 
mistakenly think to be the One True Way of Doing Things, is in fact a 
bodge that was only necessary for the 5 or so years between it being 
invented and the advent of 64-bit file position support in the FSD 
interface in 1999.  We'd never have needed Super Secret Bodge Mode in 
filesystem drivers at all if we'd had 64-bit file pointers from the 
start.  It was a workaround for a limited FSD interface.  The interface 
isn't deficient any more, and hasn't been deficient for some twelve 
years.  And the way that it is intended to work, right from the days of 
OS/2 version 1.0 onwards, is that one opens the volume with DosOpen(L), 
seeks around it with DosSetFilePtr(L), reads and writes it with DosRead 
and DosWrite, and does *no* secret, undocumented, filesystem-specific, 
incantations with FSCtrl or IOCtrl at all.  The whole-volume-file looks, 
and works, just like an ordinary file.


--- Internet Rex 2.31
 * Origin: virginmedia.com (1:261/20.999)