Gecko/20110303 Thunderbird/3.1.9
ies,comp.os.os2.programmer.misc
UTC)
comp.os.os2.utilities:189 comp.os.os2.programmer.misc:2120
From: Jonathan de Boyne Pollard
>> 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)
|
