Re: formatting to FAT32
Jonathan de Boyne Pollard
> UFAT32.DLL (that's where it would be implemented). I started
> implementing formatting support in UFAT32.DLL but never got it finished.
>
> You need to format under Windoze or use DFSee (if you have it).
>
Although not using FAT is, indeed, the better route here, I mention this
for completeness:
I have a Pure 32-Bit FORMAT replacement that will (high-level) format
FAT12, FAT16, and FAT32 volumes (where "volume" includes both disc
partitions managed by the DASD manager and volume image files created
by/suitable for VMDISK). The only caveat for the task at hand is that
it picks which FAT bitness to use according to volume size, and there's
currently no manual override option. So it will only give you a FAT32
volume if the volume is too big for FAT16 (or indeed FAT12) to cope
with. On the gripping hand, this is, generally speaking, no more than a
simple extension of existing behaviour. High-level FAT format utilities
automatically choose between FAT12 and FAT16 in this very same manner,
and (with a scant few exceptions) provide no manual override.
It should be needless to say that FAT width is independent of extensions
to the base FAT format (such as long filename support) for most
operating systems (with a few daft exceptions). There's no actual
*need* to override the bitness if all that one wants is long filenames
and suchlike. Furthermore, there's no need to override the bitness just
because something is a data exchange volume. All of the participating
operating systems will understand FAT12 and FAT16 if they understand
FAT32, after all. But that brings us back to the first point, that the
data exchange partition need not even be FAT at all to be commonly
understood, and it may well be better for it not to be.
One person (possibly) reading this will be (possibly) surprised to learn
that xe is already in possession of a FAT disc volume that was
high-level formatted with this tool. (-:
Allan
> > Unfortunately, formatting support for FAT32 was never built into
> > UFAT32.DLL (that's where it would be implemented). I started
> > implementing formatting support in UFAT32.DLL but never got it finished.
> >
> > You need to format under Windoze or use DFSee (if you have it).
> >
> Although not using FAT is, indeed, the better route here, I mention this
> for completeness:
>
> I have a Pure 32-Bit FORMAT replacement that will (high-level) format
> FAT12, FAT16, and FAT32 volumes (where "volume" includes both disc
> partitions managed by the DASD manager and volume image files created
> by/suitable for VMDISK). The only caveat for the task at hand is that
> it picks which FAT bitness to use according to volume size, and there's
> currently no manual override option.
I'm sure a lot of people are interestet in a FAT32 format utility, that just works.
Sure, we can (and do) use DFSee, but it is not very convinient.
Put it on Hobbes please, or tell us where to get it :-)
How about making the source open ? That might help someone to be able
to get ufat32 updated to include formatting - or maybe you might help doing
that job yourself ?
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Jonathan de Boyne Pollard
>
It's not finished, yet. Yes, it will format and check FAT volumes. But
I'd like to have HPFS support as well. That's mostly just a placeholder
at the moment.
> That might help someone to be able to get ufat32 updated to include
> formatting - or maybe you might help doing that job yourself ?
>
[D:\APPS\JDEBP\TAUUTIL\IFSDLL]dir /x
Directory of *
2011-03-24 18:12:36 0 0 ____D_ .
2011-03-24 18:12:36 0 0 ____D_ ..
2011-03-24 12:23:04 86,543 130 _____A FAT.DLL
2011-03-24 12:23:04 67,788 132 _____A HPFS.DLL
154,331 bytes used in 4 files found.
155,136 bytes allocated.
[D:\APPS\JDEBP\TAUUTIL\IFSDLL]
To be honest, the idea of working on, or even in any way bothering with,
a 16-bit DLL that has to adhere to a quite crude and limited API seems
to be a fairly foolish one, at this point. (-:
A much more productive thing to do, that will indeed help with this very
tool, would be to get a binary-compatible SOM workalike up and running.
Making the classes in those DLLs language-neutral and compiler-neutral
is one of the things to do before it is finished. That means making
them into SOM classes, that hence will require a SOM runtime.
Allan
> > Put it on Hobbes please, or tell us where to get it :-)
> >
>
> It's not finished, yet. Yes, it will format and check FAT volumes.
That is what we currently are missing !
BTW, does 'check' including fixing FAT32 ? The current FAT32 check
often leads to a msg like: Please run u$ Scandisk to fix your partition :-/
> But I'd like to have HPFS support as well. That's mostly just a placeholder
> at the moment.
Well, for first test version, we will all be quite happy with only FAT32 :-)
Anyway, current HPFS formatting is dead slow, so a better version would
surely be nice.
Since we often use FAT32 when we test FreeLDR - incl booting OS/2 on FAT32 -
we sure would like to have an OS/2 tool to do the format - beta or not ;-)
Jonathan de Boyne Pollard
>>
>
Aside from the part that deals with the FATs themselves, the checking
code is bitness-agnostic. So it should work the same on all bitnesses.
> The current FAT32 check often leads to a msg like: Please run u$
> Scandisk to fix your partition :-/
>
Not knowing what error causes that, or even what the real message is
(which what you write clearly is not), I cannot address specifics. The
checker recognizes the errors that I know how to recognize, and
automatically fixes the ones that I know how to automatically fix.
There's a whole repair policy section of the reference manual
documenting what errors are recognized and fixed. It's fairly long.
In general, the target problem is metadata corruption errors, and things
that IBM's CHKDSK cannot handle at all such as orphaned long filenames,
erroneously lowercased 8.3 names, and dot entries in the root
directory. (CHKDSK enters an infinite loop on that latter.) Physical
I/O problems reading/writing the medium are an entirely different kettle
of fish, and not the target problem.
>> But I'd like to have HPFS support as well. That's mostly just a
>> placeholder at the moment.
>>
> Well, for first test version, we will all be quite happy with only
> FAT32 :-)
> Anyway, current HPFS formatting is dead slow, so a better version
> would surely be nice.
>
It may be that that's as fast as it is possible to format an HPFS
volume. I don't remember it being particularly slow. (It has been a
long time since I had to format an HPFS volume.) I don't know how much
has to be done to high-level format an HPFS volume, since I haven't
written the code to do that, yet. It's probably a little more than to
high-level format a FAT volume (which pretty much only involves writing
3 things: a BPB, the FATs, and the root directory). There are a few
more data structures to write with HPFS, and they are a little more
evenly spread throughout a volume. But off the top of my head I cannot
think of a reason why high-level formatting FAT and HPFS should be
greatly different from each other as far as execution times are
concerned. From what I remember when, years ago, I last formatted HPFS
disc volumes, they weren't.
Andy
<J.deBoynePoll...@NTLWorld.COM> wrote:
> > The current FAT32 check often leads to a msg like: Please run u$
> > Scandisk to fix your partition :-/
> >
>
> Not knowing what error causes that, or even what the real message is
> (which what you write clearly is not), I cannot address specifics.
chkdsk /f on a fat32 volume under OS/2 (at least if there is anything
non-trivial that chkdsk needs to do). It basically just says it sees
something it doesn't know how to handle and to run scandisk under
windows. When I then run a chkdsk under windows it doesn't generally
even seem to do much but then when reconnected to OS/2 and a chkdsk is
run it will run clean.
Andy
--
Jonathan de Boyne Pollard
>>> Scandisk to fix your partition :-/
>>>
>> Not knowing what error causes that, or even what the real message is
>> (which what you write clearly is not), I cannot address specifics.
>>
> That really is very close to the message that you will get if you do a
> chkdsk /f on a fat32 volume under OS/2 (at least if there is anything
> non-trivial that chkdsk needs to do). It basically just says it sees
> something it doesn't know how to handle and to run scandisk under
> windows. When I then run a chkdsk under windows it doesn't generally
> even seem to do much but then when reconnected to OS/2 and a chkdsk is
> run it will run clean.
>
My goodness! Even the "u$" part?
Pointing the user at Microsoft tools for everything is rather a cop-out.
I can understand the desire for something better.
Do you actually end up in this situation a lot? Because if this is a
regular occurrence for you it might be interesting to see (a) what the
error is that SCANDISK fixes, and (b) whether my volume checker can fix
it. It might, after all, be an error that I haven't already thought of,
or caused; and I can add it to the repair list. I mentioned earlier in
this thread that I brought this up only for the sake of completeness,
nothing more. But if there's a regular problem, that actually occurs in
practice nowadays — that someone is genuinely experiencing xyrself as an
on-going annoyance from month to month — then it's worth seeing whether
CHKVOL will help.
Allan
> > Anyway, current HPFS formatting is dead slow, so a better version
> > would surely be nice.
> >
>
> It may be that that's as fast as it is possible to format an HPFS
> volume. I don't remember it being particularly slow.
Just try a 'LONG' format aka full format of the partition.
This takes maybe 10x longer for HPFS than FAT. IBM-JFS has the same
'bug' - but fortunately we got that fixed in eCS version just before GA.
> (It has been a
> long time since I had to format an HPFS volume.) I don't know how much
> has to be done to high-level format an HPFS volume, since I haven't
> written the code to do that, yet. It's probably a little more than to
> high-level format a FAT volume (which pretty much only involves writing
> 3 things: a BPB, the FATs, and the root directory). There are a few
> more data structures to write with HPFS, and they are a little more
> evenly spread throughout a volume. But off the top of my head I cannot
> think of a reason why high-level formatting FAT and HPFS should be
> greatly different from each other as far as execution times are
> concerned. From what I remember when, years ago, I last formatted HPFS
> disc volumes, they weren't.
'Short' formatting is pretty much ok, so I guess thats what you did. Sometimes
however I do prefere to cleanup a partition completely.
Allan
I see exactly same behaviour.
Andy
Well, won't say the u$ part is actually part of it :-) but the overall
message is quite close.
It occurs if I forget to eject a USB drive before pulling it out, this
is most likely to occur if I have more than one drive connected and
remember to do the eject but eject the wrong drive by mistake. Of
course a trap can cause the same condition if the USB drive is
connected.
Andy
--
Ilya Zakharevich
> Pointing the user at Microsoft tools for everything is rather a cop-out.
> I can understand the desire for something better.
>
> Do you actually end up in this situation a lot?
I would say about half of the times when chkdsk is needed...
Thanks,
Ilya
James J. Weinkam
>
> Do you actually end up in this situation a lot? Because if this is a regular occurrence for you it
> might be interesting to see (a) what the error is that SCANDISK fixes, and (b) whether my volume
> checker can fix it. It might, after all, be an error that I haven't already thought of, or caused;
> and I can add it to the repair list. I mentioned earlier in this thread that I brought this up only
> for the sake of completeness, nothing more. But if there's a regular problem, that actually occurs
> in practice nowadays — that someone is genuinely experiencing xyrself as an on-going annoyance from
> month to month — then it's worth seeing whether CHKVOL will help.
>
transfer the files to my eCS2.0 system, ensure the transferred files are complete and correct, then
erase them from the card, run chkdsk on it, and then eject it. Other than erasing the files just
before running chkdsk and ejecting the card, I never modify the card on the computer, so traps and
power failures, which do happen occasionally, do not cause trouble. Every few months, however chkdsk
finds a problem and recommends running scandisk to fix it. Just out of curiosity, I have tried
ejecting and reinserting the card when this has happened on several occasions. Sometimes after
reinsertion I can read and write even though chkdsk thinks something is wrong; on other occasions,
eCS simply says the drive is unusable. On every occasion but one running chkdsk under windows has
fixed the problem (on my version of windows, it's called chkdsk, not scandisk). On one occasion, the
windows chkdsk claimed to have fixed the problem, but eCS refused to allow the card to be used; in
the end, I had to use DFSee to zero the entire card and reformat it. After formatting a card FAT32
using DFSee, I find it necessary to eject and reinsert the card then run chkdsk before eCS will
allow it to be used; I have never needed to run the windows version for that.
Artiew
"Jonathan de Boyne Pollard" <J.deBoynePoll...@NTLWorld.COM> wrote
news:IU.D20110322.T1...@J.de.Boyne.Pollard.localhost...
> On the gripping hand, this is,
One wonders just how many people here will recognize the reference.. I do,
obviously.. :-)
We could take a poll, I suppose..
Allan
> >>> The current FAT32 check often leads to a msg like: Please run u$
> >>> Scandisk to fix your partition :-/
> >>>
> >> Not knowing what error causes that, or even what the real message is
> >> (which what you write clearly is not), I cannot address specifics.
> >>
> > That really is very close to the message that you will get if you do a
> > chkdsk /f on a fat32 volume under OS/2 (at least if there is anything
> > non-trivial that chkdsk needs to do). It basically just says it sees
> > something it doesn't know how to handle and to run scandisk under
> > windows. When I then run a chkdsk under windows it doesn't generally
> > even seem to do much but then when reconnected to OS/2 and a chkdsk is
> > run it will run clean.
> >
>
> My goodness! Even the "u$" part?
From ufat32.c:
525 printf("The copies of the FATs do not match.\n");
526 printf("Please run SCANDISK to correct this problem.\n");
[..]
613 printf("Still errors found on disk. Please run Windows 95 ScanDisk!\n");
Sorry I didn'g get it 100% correct - but I think the picture is clear anyway...
FAT32 is Open Source - go grab it to check for yourself.
> Pointing the user at Microsoft tools for everything is rather a cop-out.
> I can understand the desire for something better.
.. even seems to ask for WIN95 ;-)
> Do you actually end up in this situation a lot?
I think others have already mentioned how often this can happen.
> But if there's a regular problem, that actually occurs in
> practice nowadays that someone is genuinely experiencing xyrself as an
> on-going annoyance from month to month then it's worth seeing whether
> CHKVOL will help.
I think everyone using the FAT32 driver for OS/2 hits this problem regulary,
it is just as common, as the need/want to format FAT32 on OS/2
Where is the CHKVOL you mention available ?
Jonathan de Boyne Pollard
> is most likely to occur if I have more than one drive connected and
> remember to do the eject but eject the wrong drive by mistake. Of
> course a trap can cause the same condition if the USB drive is connected.
>
get any joy out of CHKVOL. If it's simply the case that the volume
isn't properly unmounted, and some cached metadata changes aren't
written back to the medium, then CHKVOL might yield joy. If the problem
is that this causes parts of the medium to become unreadable/unwritable,
then CHKVOL won't help because it doesn't address medium I/O errors.
The fact that you can recover from such a situation with SCANDISK is
indicative of the former being the case, not the latter.
Do you want to give CHKVOL a go?
It's not really part of a formal package like my other softwares, in
part because I'm not really at the stage of packaging up the whole that
it forms one part of into something releaseable. So you'll get an
archive file with just the bare binaries, static data files, and no
documentation; and separate documentation on my own WWW server.
Dave Yeo
I'm sure most of us know of the events at Murcheson's Eye.
Dave
Jonathan de Boyne Pollard
> problem (on my version of windows, it's called chkdsk, not scandisk).
>
You have Windows NT. What problems does its CHKDSK report having fixed?
> After formatting a card FAT32 using DFSee, I find it necessary to
> eject and reinsert the card then run chkdsk before eCS will allow it
> to be used; I have never needed to run the windows version for that.
>
I know of two things that one can fail to do that will cause such
behaviour. I expect Jan van Wijk knows the magic incantations for
formatting things on OS/2. But maybe DFSee isn't performing one of
them. Of course, the problems here could equally well be in the
filesystem driver and not the utility.
Do you want to give CHKVOL a go, too? It sounds as if my FORMAT might
be useful to you, as well.
Jonathan de Boyne Pollard
>
I've never done anything else. I've never had, or even seen, a need for
long formatting an HPFS volume.
> Sometimes however I do prefere to cleanup a partition completely.
>
There's HPFSNull in the Graham Utilities.
Jonathan de Boyne Pollard
>>
> One wonders just how many people here will recognize the reference.. I
> do, obviously.. :-)
>
There was a time when practically everyone who was in computers, or at
least those who read BYTE, would have.
> We could take a poll, I suppose..
>
A show of hands? That would be a little unfair.
Steve Wendt
>>> On the gripping hand
>>
>> One wonders just how many people here will recognize the reference..
>
> I'm sure most of us know of the events at Murcheson's Eye.
The clueless among us (hello, that's me!) have Wikipedia:
http://en.wikipedia.org/wiki/The_Gripping_Hand
If one wanted to experience "the events" for themselves, is the entire
series recommended, or are the Niven collaborations sufficient?
Dave Yeo
>>
>
> I've never done anything else. I've never had, or even seen, a need for
> long formatting an HPFS volume.
If you do a short format then do a chkdsk /f3 you will recover all the
files that were on the partition before formatting.
Dave
Dave Yeo
You need to read "A Mote in Gods Eye" before "The Gripping Hand". The
earlier Pournelle books, while interesting and adding a bit, aren't
needed for the story arc involving the Moties. (there is also a short
story that was pruned from the beginning of "A Mote in Gods Eye" that is
worth reading)
And I think these two books are excellent about showing an alien culture.
Dave
Peter Moylan
>>>
>> One wonders just how many people here will recognize the reference.. I
>> do, obviously.. :-)
>
> There was a time when practically everyone who was in computers, or at
> least those who read BYTE, would have.
I read BYTE right from the first issue, but I gave up on it long before
Pournelle started writing for it. I presume that by then it still
wasn't up to its original standard.
But, as a Niven fan, I've used "on the gripping hand" myself.
>
>> We could take a poll, I suppose..
>
> A show of hands? That would be a little unfair.
>
So mote it be.
--
Peter Moylan, Newcastle, NSW, Australia. http://www.pmoylan.org
For an e-mail address, see my web page.
Mark Dodel
<J.deBoynePoll...@NTLWorld.COM> wrote:
-> >>> The current FAT32 check often leads to a msg like: Please run u$
-> >>> Scandisk to fix your partition :-/
-> >>>
-> >> Not knowing what error causes that, or even what the real message is
-> >> (which what you write clearly is not), I cannot address specifics.
-> >>
-> > That really is very close to the message that you will get if you do a
-> > chkdsk /f on a fat32 volume under OS/2 (at least if there is anything
-> > non-trivial that chkdsk needs to do). It basically just says it sees
-> > something it doesn't know how to handle and to run scandisk under
-> > windows. When I then run a chkdsk under windows it doesn't generally
-> > even seem to do much but then when reconnected to OS/2 and a chkdsk is
-> > run it will run clean.
-> >
->
-> My goodness! Even the "u$" part?
->
-> Pointing the user at Microsoft tools for everything is rather a cop-out.
-> I can understand the desire for something better.
->
-> Do you actually end up in this situation a lot? Because if this is a
-> regular occurrence for you it might be interesting to see (a) what the
-> error is that SCANDISK fixes, and (b) whether my volume checker can fix
-> it. It might, after all, be an error that I haven't already thought of,
-> or caused; and I can add it to the repair list. I mentioned earlier in
-> this thread that I brought this up only for the sake of completeness,
-> nothing more. But if there's a regular problem, that actually occurs in
-> practice nowadays that someone is genuinely experiencing xyrself as an
-> on-going annoyance from month to month then it's worth seeing whether
-> CHKVOL will help.
I have seen this (or something real close to it) FAT32 CHKDSK error in
the past. Currently I have no windows installed anywhere, but since I
stopped playing with Linux I haven't done much with my FAT32 volume
either. I'd be willing to test it if you make it available.
Mark
--
From the eComStation 2.0 GA desktop of Mark Dodel
Warpstock 2010 - http://www.warpstock.org
Warpstock Europe 2010 - http://www.warpstock.eu
Jonathan de Boyne Pollard
>>>
>> I've never done anything else. I've never had, or even seen, a need
>> for long formatting an HPFS volume.
>>
> If you do a short format then do a chkdsk /f3 you will recover all the
> files that were on the partition before formatting.
>
I know. That's never given me a need for long formatting.
John Lawler
wrote:
It's Fyunch(click). The parenthesized part represents a click
consonant, like the ones in the SW African Khoisan languages
http://www.ethnologue.com/show_family.asp?subid=80-16
Phonological details of the click inventory of a typical
Khoisan language (Kung-Ekoka, aka !Hu, !Khung, !Ku,
!Kung, !Xu, !Xun, !Xung, Ekoka-!Xû, Kung, and Qxü) at
http://zbb.spinnwebe.com/viewtopic.php?f=10&t=2778
They didn't say which of the 5 x 16 possible clicks in
!Kung was used in Mote Prime mediators' language,
but if you can make the click sound that translates as
"tut-tut", just do one "tut" sound after "fyunch", and
that'll be a lot better than saying /klɪk/ instead.
Yours for scientific pronunciation in science fiction,
-John Lawler http://www.umich.edu/~jlawler/aue
"He who wants to persuade should put his trust
not in the right argument, but in the right word.
The power of sound has always been greater
than the power of sense." -- Joseph Conrad
Andy
I'm game to give it a shot... it is usually easilly checked by merely
pulling a USB drive without ejecting it first.
abwillis1 at gmail dot (com)
sorry for the obfuscation but I've had this email for several years
without a huge amount of spam and prefer to keep it that way.
Andy
--
Allan
> Do you want to give CHKVOL a go, too? It sounds as if my FORMAT might
> be useful to you, as well.
I, for sure, am interested (email works)
Peter Moylan
> It's Fyunch(click). The parenthesized part represents a click
> consonant, like the ones in the SW African Khoisan languages
> http://www.ethnologue.com/show_family.asp?subid=80-16
>
> Phonological details of the click inventory of a typical
> Khoisan language (Kung-Ekoka, aka !Hu, !Khung, !Ku,
> !Kung, !Xu, !Xun, !Xung, Ekoka-!Xû, Kung, and Qxü) at
> http://zbb.spinnwebe.com/viewtopic.php?f=10&t=2778
>
> They didn't say which of the 5 x 16 possible clicks in
> !Kung was used in Mote Prime mediators' language,
> but if you can make the click sound that translates as
> "tut-tut", just do one "tut" sound after "fyunch", and
> that'll be a lot better than saying /klɪk/ instead.
>
> Yours for scientific pronunciation in science fiction,
Hmm. I've always pronounced it with the more elaborate click where the
tongue collides with the bottom of the mouth. I'll have to practice
your version; it's obviously easier to pronounce.
(I think I was over 50 years old before I discovered that "tut-tut" and
"tsk-tsk" were alternative spellings of the same word.)
Jonathan de Boyne Pollard
>>
>> It's not really part of a formal package like my other softwares, in
>> part because I'm not really at the stage of packaging up the whole
>> that it forms one part of into something releaseable. So you'll get
>> an archive file with just the bare binaries, static data files, and
>> no documentation; and separate documentation on my own WWW server.
>>
> I'm game to give it a shot... it is usually easilly checked by merely
> pulling a USB drive without ejecting it first.
>
A URL has been sent to you via electronic mail. This URL is not to be
posted to Usenet or publicly archived.
The reason is simple. It's a URL for my own WWW server, running on a
machine that has a dynamically-assigned IP address. Post a URL for it to
Usenet, and that URL is hyperlinked by scads of people who like to post
Usenet discussions onto WWW pages (often pretending that they are some
sort of private discussion forum that the WWW site itself runs —
"Welcome, unregistered user. You are reading a message by Jonathan de
Boyne Pollard (guest). You may not post to Omni Consumer Web Products
Ltd's discussion group comp.os.os2.utilities. Please register an account
to post."). Then whomever is assigned the DHCP lease of this IP address,
after my machine goes elsewhere, has to suffer HTTP traffic from WWW
spiders in perpetuity. Let's not punish some poor innocent with WWW
spiders forever.
Jonathan de Boyne Pollard
> playing with Linux I haven't done much with my FAT32 volume either.
>
I've already tested it a lot. (-:
What I'm interested in are these errors that CHKDSK cannot fix, what
they are, and whether CHKVOL fixes them.
But you can try out FORMAT if you like. You might enjoy seeing what a
FAT volume formatted with FORMAT looks like in Linux. For further
enjoyment, run CHKVOL and see what Linux makes of the volume them. (I
mention Linux merely because you have it. The same enjoyment should be
obtainable with Windows NT. Although, for interesting reasons, it
cannot be obtained with DOS-Windows 9x.)
And when you have a blank FAT volume, there's probably something else
that you can try.
Evan Kirshenbaum
> Jonathan de Boyne Pollard wrote:
>>>> On the gripping hand, this is, [...]
>>>>
>>> One wonders just how many people here will recognize the reference.. I
>>> do, obviously.. :-)
>>
>> There was a time when practically everyone who was in computers, or
>> at least those who read BYTE, would have.
>
> I read BYTE right from the first issue, but I gave up on it long
> before Pournelle started writing for it. I presume that by then it
> still wasn't up to its original standard.
His column started in 1980. I think it still had a couple of decent
years left, but I didn't start reading it until '78.
--
Evan Kirshenbaum +------------------------------------
Still with HP Labs |Those who would give up essential
SF Bay Area (1982-) |Liberty, to purchase a little
Chicago (1964-1982) |temporary Safety, deserve neither
|Liberty nor Safety.
evan.kir...@gmail.com | Benjamin Franklin
John Lawler
wrote:
>
> Â Â http://www.kirshenbaum.net/
I was actually quoted in one of his columns for suggesting
the phrase "touch editing", which he apparently liked.
At that point (ca 1982) I was working on an S-100 CP/M
machine, as he suggested everybody should. *Sigh*
-John Lawler http://www.umich.edu/~jlawler/aue
"It is by universal misunderstanding that all agree.
For if, by ill luck, people understood each other,
they would never agree." - Charles Baudelaire
Peter Brooks
wrote:
>
>
> His column started in 1980. Â I think it still had a couple of decent
> years left, but I didn't start reading it until '78.
>
Uncle Ben
I hope someone is going to let us who have not read every page of Byte
in on the fun. I've programmed computers since 1957 but never have I
seen or heard of fyunch-click.
Uncle Ben
Evan Kirshenbaum
Took me a second. "It" _BYTE_.
--
Evan Kirshenbaum +------------------------------------
Still with HP Labs |If a bus station is where a bus
SF Bay Area (1982-) |stops, and a train station is where
Chicago (1964-1982) |a train stops, what does that say
|about a workstation?
evan.kir...@gmail.com
Jerry Friedman
"The gripping hand" and "fyunch(click)" are from /The Mote in God's
Eye/, a science-fiction novel (which I enjoyed) by Larry Niven and
Jerry Pournelle. Pournelle wrote a column for /Byte/.
The aliens in the novel had three arms. "On the gripping hand" is
what comes after "on the other hand".
--
Jerry Friedman
Peter Moylan
> John Lawler wrote:
>
>> It's Fyunch(click). The parenthesized part represents a click
>> consonant, like the ones in the SW African Khoisan languages
>> http://www.ethnologue.com/show_family.asp?subid=80-16
>>
>> Phonological details of the click inventory of a typical
>> Khoisan language (Kung-Ekoka, aka !Hu, !Khung, !Ku,
>> !Kung, !Xu, !Xun, !Xung, Ekoka-!Xû, Kung, and Qxü) at
>> http://zbb.spinnwebe.com/viewtopic.php?f=10&t=2778
>>
>> They didn't say which of the 5 x 16 possible clicks in
>> !Kung was used in Mote Prime mediators' language,
>> but if you can make the click sound that translates as
>> "tut-tut", just do one "tut" sound after "fyunch", and
>> that'll be a lot better than saying /klɪk/ instead.
>>
>> Yours for scientific pronunciation in science fiction,
>
> Hmm. I've always pronounced it with the more elaborate click where the
> tongue collides with the bottom of the mouth. I'll have to practice
> your version; it's obviously easier to pronounce.
On re-reading that, I realise that "the more elaborate click" is still
ambiguous. What I meant was the click that's used when talking to a
horse. Equivalently, it's the first syllable of "clip-clop".
--
Peter Moylan
Speaker to horses
Robert Bannister
> Peter Brooks<peter.h....@gmail.com> writes:
>
>> On Mar 28, 5:51 pm, Evan Kirshenbaum<evan.kirshenb...@gmail.com>
>> wrote:
>>>
>>> His column started in 1980. I think it still had a couple of
>>> decent years left, but I didn't start reading it until '78.
>>>
>> So, you are Merlin, and ICMFP.
>
> Took me a second. "It" _BYTE_.
>
I only had to read it five times before I worked that out. I'm glad I
didn't have to pester you for an explanation.
--
Rob Bannister
Mark Dodel
<J.deBoynePoll...@NTLWorld.COM> wrote:
-> > Currently I have no windows installed anywhere, but since I stopped
-> > playing with Linux I haven't done much with my FAT32 volume either.
-> > I'd be willing to test [CHKVOL] if you make it available.
-> >
->
-> I've already tested it a lot. (-:
->
-> What I'm interested in are these errors that CHKDSK cannot fix, what
-> they are, and whether CHKVOL fixes them.
->
-> But you can try out FORMAT if you like. You might enjoy seeing what a
-> FAT volume formatted with FORMAT looks like in Linux. For further
-> enjoyment, run CHKVOL and see what Linux makes of the volume them. (I
-> mention Linux merely because you have it. The same enjoyment should be
-> obtainable with Windows NT. Although, for interesting reasons, it
-> cannot be obtained with DOS-Windows 9x.)
->
-> And when you have a blank FAT volume, there's probably something else
-> that you can try.
Actually I no longer have Linux either. I had to delete all the
OpenSUSE volumes because when I last "updated" it, it overwrote the
MBR, somehow changed the order of all the partitions and I couldn't
boot eCS any more. What was weird was I had everything working fine
before that. I'm hesitant to screw with Linux anymore. Back then I
had both my T42p and my T61 so I could risk it. Unless I pick up a
cheap laptop to play with. I should have bought one of those T43s
they had for sale at Warpstock last year.
Jonathan de Boyne Pollard
> OpenSUSE volumes because when I last "updated" it, it overwrote the
> MBR, somehow changed the order of all the partitions and I couldn't
> boot eCS any more. What was weird was I had everything working fine
> before that. I'm hesitant to screw with Linux anymore.
>
It's interesting to read this. Many years ago, Microsoft was Evil in
many people's eyes because installing Windows would overwrite their boot
managers and prevent them from rebooting back into their old operating
systems; and Linux was One of the Good Guys because it didn't do this.
Nowadays, I observe that exactly the sort of things are said about modern
Linux distributions, about how they screw up prior boot arrangements and
suchlike, as used to be said about Microsoft Windows.
Well you can always have fun CHKVOLling your FAT32 volume, even if you
don't get to see what the result looks like in Linux. (-:
Jonathan de Boyne Pollard
>> be useful to you, as well.
>>
> I, for sure, am interested (email works)
>
as already stated.
Mark Dodel
<J.deBoynePoll...@NTLWorld.COM> wrote:
-> > Actually I no longer have Linux either. I had to delete all the
-> > OpenSUSE volumes because when I last "updated" it, it overwrote the
-> > MBR, somehow changed the order of all the partitions and I couldn't
-> > boot eCS any more. What was weird was I had everything working fine
-> > before that. I'm hesitant to screw with Linux anymore.
-> >
->
-> It's interesting to read this. Many years ago, Microsoft was Evil in
-> many people's eyes because installing Windows would overwrite their boot
-> managers and prevent them from rebooting back into their old operating
-> systems; and Linux was One of the Good Guys because it didn't do this.
-> Nowadays, I observe that exactly the sort of things are said about modern
-> Linux distributions, about how they screw up prior boot arrangements and
-> suchlike, as used to be said about Microsoft Windows.
->
-> Well you can always have fun CHKVOLling your FAT32 volume, even if you
-> don't get to see what the result looks like in Linux. (-:
I knew that a fresh install of most Linux distros would do this if I
wasn't real careful about placing grub in /root, but I never imagined
an update of an existing install would do it. And this T61 came from
Lenovo with just SLED 10 installed, so I had some experience with SLED
and OpenSUSE before. I actually liked OpenSUSE, better then some
other versions, but I'm waiting to see someone say they had success
with coexisting with eCS before I try it again.
mark
Jonathan de Boyne Pollard
> files that were on the partition before formatting.
>
statement isn't strictly true, and the *way* that it isn't true is in
fact a wart in CHKDSK. (-:
Will Honea
There was a hiccup in one of the openSUSE 11.4 RCs that pulled this stunt
causing much grief. I've not seen it with the release - the grub
installation has honored the existing schema quite nicely. Sure caused a
lot of traffic on the fora when it happened, tho.
--
Will Honea
Jonathan de Boyne Pollard
>
This is just to let you know that I sent a reply to your latest message,
with a whole load of information and instructions. But your ISP has
decided, in its "wisdom", to blacklist my entire ISP for some unknown
reason. It bounced the mail. Here's a very short version, for Usenet:
Download the new ZIP file, set up your DPATH to include the Data
directory supplied, don't forget to unpack the DLLs (just put the DLL
directory on your ENDLIBPATH or something), and look at the more
detailed output.
Jonathan de Boyne Pollard
>> for some unknown reason.
>>
> NTL's mail server on <http://www.spamhaus.org/lookup.lasso>. Also,
> what did the rejection message say?
>
The rejection message stated in no uncertain terms that the people at
PenTeleData had added NTL to their private black list. It even gave the
IP address of NTL's outbound SMTP Relay client. And it pointed to
http://www.ptd.net/RBL . Read it and weep. PenTeleData operates a
private blacklist of its own and it just added NTL to it for an unknown
reason. Welcome to the balkanization of SMTP mail.
Jonathan de Boyne Pollard
>>
> I read it. It seems to be pretty clear. Did you contact your
> postmaster and ask them to read it?
>
I got on with the job that I'm actually trying to do, instead.
>> PenTeleData operates a private blacklist of its own and it just added
>> NTL to it for an unknown reason.
>>
> Unknown? Did you read "The only way your host gets listed is by it
> sending email to a spamtrap email address,"?
>
Yes, and I'm experienced enough in these things to know that that's not
necessarily the truth. The truth is unknown in this instance. Kid,
stop trying to solve this problem. I do know my way around SMTP
electronic mail, having written the odd mail server here and there, and
have enough experience with dancing the same silly dances over and over
again to immediately know when something is a lost cause, and I don't
have the time to waste right now in going through the basics with
someone on Usenet, thank you. I'm trying to give people a utility for
checking their FAT32 volumes.
Mark Dodel
<J.deBoynePoll...@NTLWorld.COM> wrote:
-> > I'd be willing to test [CHKVOL] if you make it available.
-> >
-> This is just to let you know that I sent a reply to your latest message,
-> with a whole load of information and instructions. But your ISP has
-> decided, in its "wisdom", to blacklist my entire ISP for some unknown
-> reason. It bounced the mail. Here's a very short version, for Usenet:
-> Download the new ZIP file, set up your DPATH to include the Data
-> directory supplied, don't forget to unpack the DLLs (just put the DLL
-> directory on your ENDLIBPATH or something), and look at the more
-> detailed output.
OK I did send you a new report, as well as a different email address
with a hopefully less problematic provider.
Jonathan de Boyne Pollard
> often leads to a msg like: Please run u$ Scandisk to fix your
> partition :-/
>
Allan now knows that the answer to this is "yes", he being the first
person other than me to have successfully checked a FAT32 partition with
CHKVOL. He's also seen CHKVOL tell him about some oddities in his FATs
that not even Microsoft's CHKDSK (from Windows NT) was telling him
about. (-:
Others have not been so lucky. It turns out that there's a
not-so-well-known problem with the FAT32 IFS driver and access to
*large* partitions (certainly larger than Allan's ~4GiB at any rate)
that affects any program that tries to read the partition directly, as
of course CHKVOL does. One cannot even seek to block #0 and read it.
I'm trying a few workaround strategies for this.
Ilya Zakharevich
You might be seeing the same problem as what I reported about a year
ago: reading by anything larger than 512 B blocks is "unreliable" -
gives junk. But, IIRC, I have seen it even with smallish partitions
(do not remember the details - it should be on Usenet).
E.g., my Perl module for post-mortems on FAT reads by 512 B when run
on OS/2 (of course, this is painfully slow). But at least I did not
see any OTHER problem with my test cases...
Ilya
Artiew
"Jerry Friedman" <jerry_f...@yahoo.com> wrote in message
news:ef2dea59-42f3-4b0e...@r19g2000prm.googlegroups.com...
On Mar 28, 10:08 am, Uncle Ben <bgr...@nycap.rr.com> wrote:
> On Mar 27, 12:26 am, Jonathan de Boyne Pollard <J.deBoynePollard-
>
> newsgro...@NTLWorld.COM> wrote:
> > >> On the gripping hand, this is, [...]
>
> > > One wonders just how many people here will recognize the reference.. I
> > > do, obviously.. :-)
>
> I hope someone is going to let us who have not read every page of Byte
> in on the fun. I've programmed computers since 1957 but never have I
> seen or heard of fyunch-click.
"The gripping hand" and "fyunch(click)" are from /The Mote in God's
Eye/, a science-fiction novel (which I enjoyed) by Larry Niven and
Jerry Pournelle. Pournelle wrote a column for /Byte/.
The aliens in the novel had three arms. "On the gripping hand" is
what comes after "on the other hand".
--
Jerry Friedman
And also the sequel "The Gripping Hand" by the same authors.
The gripping hand was the third hand, which was stronger and used for
gripping things, while the other two were used for purposes that needed a
greater degree of fine coordination.
The conversation is of the type you get when there are a bunch of "old guys"
in the same room.. (and yes, I guess I couint as one of those..).
Jonathan de Boyne Pollard
>> not-so-well-known problem with the FAT32 IFS driver and access to
>> *large* partitions (certainly larger than Allan's ~4GiB at any rate)
>> that affects any program that tries to read the partition directly,
>> as of course CHKVOL does. One cannot even seek to block #0 and read
>> it. I'm trying a few workaround strategies for this.
>>
> You might be seeing the same problem as what I reported about a year
> ago: reading by anything larger than 512 B blocks is "unreliable" -
> gives junk.
>
No, this is definitely a seeking problem. DosSetFilePtr() returns
ERROR_SEEK. M. Dodel removed his IFS driver and the problem went away.
But with it present, that's what happens. So we're seeing what
DosSetFilePtrL() does.
KO Myung-Hun
See the following threads.
http://tech.groups.yahoo.com/group/fat32dev/message/514
And
http://tech.groups.yahoo.com/group/fat32dev/message/675
Especially for the code snippets
http://tech.groups.yahoo.com/group/fat32dev/message/680
Jonathan de Boyne Pollard wrote:
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.0.11
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
Jonathan de Boyne Pollard
has to be independent of filesystem format. How close are you to making
ordinary sector-level access with DosSetFilePtr/DosRead/DosWrite just
work as it ought? Did anyone try the DosSetFilePtrL() route that we're
trying now? Did you try implementing the FS_CHGFILEPTRL method, as was
suggested but never commented upon?
Trevor Hemsley
<spam...@library.lspace.org.invalid> wrote:
> Especially if you keep blaming the
> list operator without knowing whether the listing is legitimate.
To blacklist all 4 million customers of one of the top 3 ISPs in the UK does
seem a little strange though.
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
Jonathan de Boyne Pollard
>>
>
Your "help" comprises teaching your grandfather to suck eggs. It's
stupid, thoughtless, and inane. I know the basics, kid. I don't need
someone to hand-hold me through them on Usenet. And you'd know this if
you put the old brain box into gear and thought. You've *seen* me
hand-hold people through the basics often enough. I've been doing it
for nigh on 20 years.
>> Yes, and I'm experienced enough in these things to know that that's
>> not necessarily the truth. The truth is unknown in this instance.
>>
> But not experienced enough to know that it probably is.
>
On the contrary, I clearly have enough experience to have thought of
something that you clearly haven't thought of. And it's a fairly
obvious thing. Apply a little brainpower, for goodness' sake.
>> I do know my way around SMTP electronic mail, having written the odd
>> mail server here and there, and have enough experience with dancing
>> the same silly dances over and over again to immediately know when
>> something is a lost cause, and I don't have the time to waste right
>> now in going through the basics with someone on Usenet, thank you.
>> I'm trying to give people a utility for checking their FAT32 volumes.
>>
> Trying to get a listing removed without fixing the problem?
>
As I said, thoughtless and inane. Apply that brain, kid. My ISP has
been blacklisted by PenTeleData. Who says that it is *anything at all
to do with me*? That would be astonishingly presumptuous to think
that. There's about 10 million customers, there.
> Especially if you keep blaming the list operator without knowing
> whether the listing is legitimate.
>
The list operator can list whomever it likes, however sensible or
foolish that may be; that's its prerogative. But you're trying to have
your cake and eat it. You're trying to argue that there's a possibility
that the listing is not legitimate in the same breath as you're trying
to argue that all listings are in accordance with what the WWW page says
because listings are only ever made legitimately. You cannot have both
at the same time. The Clue which is not percolating through to you,
that you're risibly trying to paint as inexperience, is that *the WWW
page isn't necessarily the truth*. Good grief, kid! People don't
always tell the truth on their WWW sites. Indeed, people often
*deliberately* don't explain what countermeasures they use against
foes. Nor, indeed, do they always stick to their own blacklisting
policies. Once you've had as much experience with these silly dances as
I'm speaking from, you'll know that what I wrote above is the case.
There's no reason to believe that the WWW page is necessarily the truth,
and no reason to suppose that we know *any part at all* of the reason
for PenTeleData deciding to blacklist an entire ISP. I said that the
truth is unknown, and it is. For all you or I know, the postmaster at
PenTeleData could have made a typing error, could have made an emergency
listing bypassing published procedure to deal with something of the
moment, or could be working to some quite different unpublished
blacklisting policy. Your assumption that the only possible chain of
events that least to this sort of thing happening is the one chain of
events laid out on a WWW page is simply naive, and your assumption that
the chain of events laid out on the WWW page would have anything to do
with me even were it the case is (a) foolish and not thought through at
all (given that M. Dodel's mailbox clearly is *not* a honeypot), (b)
professionally insulting (given the clear presumption on your part that
I therefore must have sent some junk mail, since that's the stated
prerequisite), and (c) sophomorically free from any thought of the fact
that there are several million other people in the equation.
Jonathan de Boyne Pollard
> UK does seem a little strange though.
>
that it creates incentive, for starters. "Look, you're going to get 10
million customers complaining at you. You'd better dance to my tune."
And even, just for the sake of exposition, buying M. Metz's naive and
inexperienced contention that the blacklisting is done as it is claimed
to be done, and no-one makes any errors, or does things for expediency,
or tries to hoodwink the UBM senders, it's fairly clear that this sort
of thing can happen often. Consider. Just *one* of those 10 million
customers happens to hit a honeypot mailbox, sending through Virgin
Media's SMTP Relay clients, and in response PenTeleData blacklists
Virgin Media's SMTP Relay client, as that was the source. If that
customer were a genuine Unsolicited *Bulk* Mail sender, then of course
xe'd probably have sent more than one message to more than one honeypot,
that being the nature of *bulk* mail after all, and probably thereby
routed mail via several of Virgin Media's SMTP Relay clients, causing
them all to be blacklisted. One bulk mail run, by one out of 10
million, and suddenly an entire ISP's SMTP Relay client bank is blacklisted.
But as I pointed out twice, the truth is unknown. There's no reason to
suppose that the published model is the true model. People aren't
obliged to tell everyone how they are blacklisting people, nor are they
obliged to stick to their own blacklisting rules. Indeed, many people
would be most upset if they weren't allowed the freedom to blacklist as
they like, so that they can be flexible in the face of events, even
though they had a published set of rules. And the people who are
already hoodwinking UBM senders with honeypot mailboxes would strongly
resist the idea that they had to be entirely transparent about what they
are doing, because, for starters, not telling people about the honeypots
is the main idea.
Frankly, as the innocent third parties clearly caught in the fallout, M.
Metz's professionally insulting presumptions notwithstanding, it's not
our business and not our fight. Moreover, why should any of us give any
ISP the satisfaction of using us as clubs to bully our own ISP? For
that is exactly what this "tell your postmaster" stuff is all about. (I
am, in fact, my own postmaster, in the usual case. As I said, I know my
way around SMTP.) PenTeleData makes (it hopes) 10 million people's
lives every so slightly more difficult, and then tells them that they
should complain to Virgin Media about it. It's using an ISP's customers
as pawns. It may well be the only weapon available, the truth of which
claim is another discussion all in itself, but it doesn't mean that the
pawns are obliged either to like it or to cooperate. It's not
PenTeleData that the pawns have a contract with, for one thing. If
someone told you that xe was going to prevent you from talking to
another person because a third party that neither you even know had done
something completely unrelated to either of you, would you be inclined
to cooperation? You'd probably ask why the heck the two of you are
being roped in at all. It's a bizarre idea when presented in the world
of everyday discourse, but it's normal for the world of SMTP electronic
mail.
Again, as I said, welcome to the balkanization of SMTP mail. If you
look around a bit, you'll see this happening all over. Just looking at
PenTeleData one can find reported that it blacklisted GMail
(72.14.204.xxx) in 2007, Yahoo! (72.14.246.250) in 2007, Comcast
(76.96.30.48) in 2007, and Orange France (80.12.242.26) in 2009. One
can find the same for many other ISPs. There's a 2006-01-26 article by
Jack Schofield, computer editor of The Guardian, all about NTL
blacklisting a whole load of other ISPs, including TescoNET (the running
of which, as I recall, was outsourced to NTL itself at the time). To
reiterate what I said at the start: The blanket option happens quite
often. Those of us with experience are long-since familiar with it and
the silly dances that ensue. (-:
Allan
> > Especially for the code snippets
> >
> > http://tech.groups.yahoo.com/group/fat32dev/message/680
> >
> They're not really any use at all. The code to read and write a volume
> has to be independent of filesystem format. How close are you to making
> ordinary sector-level access with DosSetFilePtr/DosRead/DosWrite just
> work as it ought? Did anyone try the DosSetFilePtrL() route that we're
> trying now?
These bugs have been known for years, as you can see on the data of
the msgs. Doesn't look like anyone has been working on it.
I hit the same issues - both DosSetFilePtr and DosWrite just returns errors -
when writing the installer for osFree. Had to use the IOCtrl interface that
Ko showed you for FAT32 insted. Although this interface should work on
HPFS too, it is unfortunately not implemented in JFS, so this isn't usefull
for all IFS's either :-/
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
KO Myung-Hun
Jonathan de Boyne Pollard wrote:
>> Especially for the code snippets
>>
>> http://tech.groups.yahoo.com/group/fat32dev/message/680
>>
> They're not really any use at all. The code to read and write a volume
> has to be independent of filesystem format.
Hmm... There is the other approach, so called workaround.
And what do you think about sector-mode of HPFS ? Is it also not any use
at all because it is not independent of filesystem format ?
Without this, you cannot access over 2GB area using DASD method with
16bits IFS such as HPFS. So you cannot access over 2GB area using DASD
with HPFS386, which is not support sector-mode.
I think, you'd better make an abstraction layer for an unified access to
the volume using DASD.
Anyway, I just wanted to tell you the other method to implement your
program for FAT32.
So if you don't want this method, just do not use it.
That's all.
> How close are you to making
> ordinary sector-level access with DosSetFilePtr/DosRead/DosWrite just
> work as it ought?
If you read all the threads, you coulud know that
DosSetFilePtr()/DosRead() worked as expected, but DosWrite().
> Did anyone try the DosSetFilePtrL() route that we're
> trying now? Did you try implementing the FS_CHGFILEPTRL method, as was
> suggested but never commented upon?
>
Why do you think xxxL APIs and entry points are relevant to this problem ?
If so, can you explain how plain HPFS work even without xxxL APIs and
entry points ?
Jonathan de Boyne Pollard
> the msgs. Doesn't look like anyone has been working on it.
>
let's introduce FS_CHGFILEPTRL and see whether it fixes the problem M.
Ko stated that xe didn't know why this was happening. Here's a
hypothesis that seems reasonable. The data that we have are these:
* Raw access with DosRead/DosWrite/DosSetFilePtr works just fine on your
~4GiB FAT32 volume.
* DosSetFilePtr() returns ERROR_SEEK on larger FAT32 volumes.
* M. Ko reports that the FS_CHGFILEPTR function of the IFS isn't even
being called in such circumstances.
The thing to remember, to start with, is that the whole "sector mode"
thing is a red herring. That's purely within the IFS driver itself. The
kernel knows nothing of it. As far as the kernel is concerned raw access
is *always* byte-by-byte and offsets are byte offsets. Once one gets
one's head around that, then a hypothesis positively leaps out. The OS/2
version 4.5 kernel, remember, has 64-bit file pointer support. So it's a
fair chance that what's happening is that the kernel is saying "Oho! The
application is trying to move the file pointer about, and this disc
volume is larger than 4GiB. So I'll use 64-bit file pointer
mechanisms.". The problem in such a circumstance is that FAT32.IFS
doesn't have a FS_CHGFILEPTRL entrypoint. The kernel sees a non-existent
entrypoint, and rather than falling back to the 32-bit one it simply
returns ERROR_SEEK.
By the way, in answer to the other question that came up all those years
ago: If you look at the VirtualBox shared folders OS/2 IFS driver
skeleton code, you'll see three out of four entrypoints complete with
function signatures. The four entrypoints are thus FS_CHGFILEPTR,
FS_CHGFILEPTRL, FS32_CHGFILEPTR, and FS32_CHGFILEPTRL. The entrypoints
ending in "L" take a 64-bit file offset value instead of a 32-bit one,
and the entrypoints beginning "FS32_" are 32-bit functions instead of
16-bit ones.
If this hypothesis is correct — and it's a fairly credible one — then
giving the kernel an actual "L" entrypoint to call when it wants to seek
around within a >4GiB volume will stop the ERROR_SEEKs. Making such a
function is dead easy. Just copy FS_CHGFILEPTRL, change the lOffset
parameter to a 64-bit signed integer, and (for now) add a check on the
desired to position to ensure that it is less than 0x1_0000_0000. Then
set the FSA_LARGEFILE attribute. This might necessitate doing
FS_NEWSIZEL, FS_CANCELLOCKREQUESTL, and FS_FILELOCKSL, as well; but the
same approach applies. Indeed, one could *rename* the non-"L" functions
to the "L" functions and then make the non-"L" functions into wrappers
that call the "L" functions. Something like the code at the end of this
message, which is off the top of my head, perhaps. (I suggest that those
with JFS source code access check what SFFSI structure is passed to an
"L" function.)
M. Ko has the ability to modify, recompile, and use FAT32.IFS, and you
apparently have JFS source code access. If xe does that, and you check
the SFFSI structure, I can supply CHKVOL to test against a >4GiB volume.
int far pascal FS_CHGFILEPTRL(
struct sffsi far * psffsi, /* psffsi */
struct sffsd far * psffsd, /* psffsd */
LONGLONG lOffset, /* offset */
unsigned short usType, /* type */
unsigned short IOFlag /* IOflag */
)
{
PVOLINFO pVolInfo;
POPENINFO pOpenInfo = GetOpenInfo(psffsd);
LONGLONG lNewOffset;
USHORT rc;
if (f32Parms.fMessageActive& LOG_FS)
Message("FS_CHGFILEPTRL, Mode %d - offset %lld, current offset=%lu",
usType, lOffset, psffsi->sfi_position);
pVolInfo = GetVolInfo(psffsi->sfi_hVPB);
if (IsDriveLocked(pVolInfo))
return ERROR_DRIVE_LOCKED;
switch (usType)
{
case CFP_RELBEGIN :
if (lOffset< 0)
{
rc = ERROR_NEGATIVE_SEEK;
goto FS_CHGFILEPTRLEXIT;
}
lNewOffset = lOffset;
break;
case CFP_RELCUR :
lNewOffset = psffsi->sfi_position + lOffset;
break;
case CFP_RELEND :
lNewOffset = psffsi->sfi_size + lOffset;
break;
}
if (!IsDosSession()&& lNewOffset< 0)
{
rc = ERROR_NEGATIVE_SEEK;
goto FS_CHGFILEPTRLEXIT;
}
/* This ensures that all positions are in the first 4GiB, preserving
the semantics of 32-bit file pointers. Of course, with true large
file support, this test is unnecessary and wrong. But we're not
setting out to do that at the moment. */
if (lNewOffset> (ULONGLONG)0xFFFFFFFF)
{
rc = ERROR_NEGATIVE_SEEK;
goto FS_CHGFILEPTRLEXIT;
}
/* Yes, we're casting to a ULONGLONG and then assigning into a ULONG.
This is so that we don't have to revisit this down the line. */
if (psffsi->sfi_position != (ULONGLONG)lNewOffset)
{
psffsi->sfi_position = (ULONGLONG)lNewOffset;
pOpenInfo->ulCurCluster = FAT_EOF;
}
rc = 0;
FS_CHGFILEPTRLEXIT:
if (f32Parms.fMessageActive& LOG_FS)
Message("FS_CHGFILEPTRL returned %u", rc);
return rc;
}
int far pascal FS_CHGFILEPTR(
struct sffsi far * psffsi, /* psffsi */
struct sffsd far * psffsd, /* psffsd */
LONG lOffset, /* offset */
unsigned short usType, /* type */
unsigned short IOFlag /* IOflag */
)
{
/* The 32-bit function simply devolves to the 64-bit one.
If the SFFFSI structures differ, we might not be able to
do things this simply, and might have to cut and paste
instead. */
return FS_CHGFILEPTRL(psffsi, psffsd, lOffset, usType, IOFlag);
}
Jonathan de Boyne Pollard
> use at all because it is not independent of filesystem format ?
>
It's certainly not desirable. I'd much prefer everything to use the
"new" (if something from 1999 can be called that any more) OS/2 4.5
"raw" paradigm where possible. Open with DosOpenL, seek around with
DosSetFilePtrL, and read and write with DosRead/DosWrite. No magic
filesystem-specific FSCtls or IOCtls at all.
> I think, you'd better make an abstraction layer for an unified access
> to the volume using DASD.
>
I *have* an abstraction layer. That's why filesystem-specific bodges
are undesirable. The abstraction layer has no knowledge of filesystem
format, and it's a godawful bodge to put it in, especially when it's
clear from the Toolkit doco that OS/2 4.5 was aiming for a nice clean
universal interface free from filesystem-specific bodges.
>> How close are you to making ordinary sector-level access with
>> DosSetFilePtr/DosRead/DosWrite just work as it ought?
>>
> If you read all the threads, you coulud know that
> DosSetFilePtr()/DosRead() worked as expected, but DosWrite().
>
No, they *do not* work as expected. (And there was no thread from 2005
that actually stated otherwise. Indeed, we have you yourself saying
that "I don't know what the cause is." and "HPFS386 also has a similar
problem." and "I'll look into [it] more.".) DosSetFilePtr() still
returns ERROR_SEEK, just as it did in 2005. It's returning ERROR_SEEK
for Mark Dodel, and it's returning ERROR_SEEK for Andy WIllis. They've
both independently sent me logs showing this. (I instrumented CHKVOL to
print out the return code from the system call.) Andy Willis has also
kindly tested DosSetFilePtrL and that returns ERROR_SEEK too. Working
on the assumption that they both have the latest release of the FAT32
filesystem driver, which I have no reason to doubt, this problem has
*not* been fixed and the calls do *not* work as they ought to. And we
even have you stating that HPFS386.IFS, also lacking the FS_CHGFILEPTRL
entrypoint, has the same problem.
Mark Dodel has confirmed that this is FAT32.IFS causing this, by the
simple expedient of disabling the filesystem driver and using CHKVOL
/FS:FAT, which uses the same access method for reading/writing the
volume contents (it being filesystem-agnostic and all). That worked, he
told me. DosSetFilePtr() didn't return ERROR_SEEK. And Allan Holm has
provided a useful datum, since he has managed to get things to work with
the FAT32.IFS driver installed, but on a ~4GiB volume.
Ilya Zakharevich
> Ko stated that xe didn't know why this was happening. Here's a
> hypothesis that seems reasonable. The data that we have are these:
> * Raw access with DosRead/DosWrite/DosSetFilePtr works just fine on your
> ~4GiB FAT32 volume.
No. We know that it does not work OK. In my experience, it works OK
with 512 B reads, not with 64K reads (and IIRC, not even with 4K reads).
> * DosSetFilePtr() returns ERROR_SEEK on larger FAT32 volumes.
> * M. Ko reports that the FS_CHGFILEPTR function of the IFS isn't even
> being called in such circumstances.
Ilya
Ilya Zakharevich
> Why do you think xxxL APIs and entry points are relevant to this problem ?
>
> If so, can you explain how plain HPFS work even without xxxL APIs and
> entry points ?
They do not. EVERY program must contain A HACK if it wants to access
an HPFS partition raw. E.g., I cannot write a simple Perl script
which would analyze some particular facet of HPFS layout - it would not
even be able to read the structures from disk.
Yours,
Ilya
P.S. Unfortunately, AFAIU, one cannot add *L functions to FAT32 via a
simple hack: FAT32 volumes may contain FILES between 2GB and 4GB in
size, and these added entry points MUST ALSO support these files.
So one would need a lot of testing to check that the added entry
points do not affect operation on ordinary files in negative way. And
since the interaction of functions with *L with the kernel is (?)
undocumented, this take some effort....
Allan
> M. Ko has the ability to modify, recompile, and use FAT32.IFS, and you
> apparently have JFS source code access.
Not really.
But both IFS's are Open Source, and can be found on Netlabs.
You are very welcome to download them, and fix the problems ;-)
It might in the end be a better solution even for you, so you don't have
to create any bodges :-)
I think the FAT32 driver in Netlabs SVN is up to date - the JFS codeon
(in ftp) is however rather old, and we might have to find that somewhere
else, if needed.
Jonathan de Boyne Pollard
>
This brings up an interesting point that I was going to query. It's
said that JFS for OS/2 source code is available, and that's certainly
the received wisdom that's been repeated over the years. But yesterday
was the first day that I actually went looking for the source code. (I
wanted to check the sffsi structure and see what it did about current
file position values.) I couldn't find it. It's not on the SourceForge
WWW site for JFS, which only has Linux source. There's only binaries on
Hobbes. LEO doesn't do software any more. Netlabs doesn't have a JFS
project listed. Where, actually, *is* this source for OS/2 JFS that is
supposed to exist?
Jonathan de Boyne Pollard
>> your ~4GiB FAT32 volume.
>>
> No. We know that it does not work OK.
>
Yes, we know that it works OK when reading and writing whole disc
sectors using the raw interface. Allan has run CHKVOL all of the way
through quite successfully, twice even, and sent me the log of its
output as proof. The fact that I know how big a volume it is is
testament to that. The volume size is part of the summary that CHKVOL
prints out when it has finished.
> In my experience, it works OK with 512 B reads, not with 64K reads
> (and IIRC, not even with 4K reads).
>
I wouldn't be surprised by several of the 16-bit innards of OS/2 having
problems with I/O in chunks of 64KiB. That's one of the reasons that
the FORMAT code in my FAT.DLL caps cluster sizes at 32KiB when it is in
IBM OS/2 compatibility mode, so that it avoids creating volumes that
OS/2 might then have trouble with. (Some of the other reasons are the
same as Microsoft's. See KnowledgeBase article Q184006 et al.)
Jonathan de Boyne Pollard
> simple hack: FAT32 volumes may contain FILES between 2GB and 4GB in
> size, and these added entry points MUST ALSO support these files.
>
Bah! It's not exactly rocket science to create exactly that sort of
simple support. One is doing no more than a little bit of arithmetic
and ending up with a value to plonk into a field of the sffsi
structure. One merely has to ensure that the "L" entrypoints cannot end
up with anything at the end of their calculations that's outwith the
possible range of 32-bit values that the non-"L" entrypoints could have
calculated, and fail appropriately in such cases. The hard parts are
(a) finding the documentation for the sffsi structure that is passed to
the "L" entrypoints, and (b) having the "L" entrypoints do *more* than
their 32-bit equivalents.
Dave Yeo
There is ftp://ftp.netlabs.org/pub/openjfs/openjfs-20070128203903.zip
which is full of source from 2003 and looks like a copy of a .cvs directory.
As far as I know the newer JFS is closed source even though they used
some of the GPLed Linux JFS.
Dave
KO Myung-Hun
Jonathan de Boyne Pollard wrote:
>> And what do you think about sector-mode of HPFS ? Is it also not any
>> use at all because it is not independent of filesystem format ?
>>
>
> It's certainly not desirable. I'd much prefer everything to use the
> "new" (if something from 1999 can be called that any more) OS/2 4.5
> "raw" paradigm where possible. Open with DosOpenL, seek around with
> DosSetFilePtrL, and read and write with DosRead/DosWrite. No magic
> filesystem-specific FSCtls or IOCtls at all.
>
Can you access to the area over 2GB or 4GB of HPFS partition using
HPFS.IFS or HPFS386.IFS with 'L' APIs ?
Even though you call 'L' APIs, you cannot overcome the defect of IFSes
itself if IFSes does not support 64bit IO.
'L' APIs are for 64bit IO IFSes such as JFS and UDF. Of course, kernel
can forward 'L' APIs calls to non-'L' APIs calls.
Nevertheless, unless all the IFSes are rewritten for 64bit IO, the
changed is nothing.
Of course, I agree that it's the best to use 'L' APIs only without any
hack specific to IFSes for the consistency.
>> I think, you'd better make an abstraction layer for an unified access
>> to the volume using DASD.
>>
>
> I *have* an abstraction layer. That's why filesystem-specific bodges
> are undesirable. The abstraction layer has no knowledge of filesystem
> format, and it's a godawful bodge to put it in, especially when it's
> clear from the Toolkit doco that OS/2 4.5 was aiming for a nice clean
> universal interface free from filesystem-specific bodges.
>
What a curious! What is your abstraction layer ? You mean
DosRead()/DosWrite() ? Hmm...
>>> How close are you to making ordinary sector-level access with
>>> DosSetFilePtr/DosRead/DosWrite just work as it ought?
>>>
>> If you read all the threads, you coulud know that
>> DosSetFilePtr()/DosRead() worked as expected, but DosWrite().
>>
>
> No, they *do not* work as expected. (And there was no thread from 2005
> that actually stated otherwise. Indeed, we have you yourself saying
> that "I don't know what the cause is." and "HPFS386 also has a similar
> problem." and "I'll look into [it] more.".) DosSetFilePtr() still
> returns ERROR_SEEK, just as it did in 2005. It's returning ERROR_SEEK
> for Mark Dodel, and it's returning ERROR_SEEK for Andy WIllis. They've
> both independently sent me logs showing this. (I instrumented CHKVOL to
> print out the return code from the system call.) Andy Willis has also
> kindly tested DosSetFilePtrL and that returns ERROR_SEEK too. Working
> on the assumption that they both have the latest release of the FAT32
> filesystem driver, which I have no reason to doubt, this problem has
> *not* been fixed and the calls do *not* work as they ought to. And we
> even have you stating that HPFS386.IFS, also lacking the FS_CHGFILEPTRL
> entrypoint, has the same problem.
>
Ok. I didn't release the 0.9.14 of FAT32.IFS. But svn repo on netlabs
already has the fixes for the seeking problem.
See the following changeset.
http://svn.netlabs.org/fat32/changeset/91
The cause of seeking problem is not the absence of 'L' entry points.
It's due to the overflow of 32bits variable. If it's used as a signed
variable, it can express up to 2GB, which is the case of FAT32, but if
it's as unsigned variable, up to 4GB.
Due to this, some volume smaller than 4GB worked fine, because it does
not cause a overflow of 32bits variable. But some volume larger then 4GB
did not work.
To overcome this limitation, FAT32 introduced sector-io mode as HPFS does.
That's all.
'L' APIs and 'L' entry points are not relevant at all.
> Mark Dodel has confirmed that this is FAT32.IFS causing this, by the
> simple expedient of disabling the filesystem driver and using CHKVOL
> /FS:FAT, which uses the same access method for reading/writing the
> volume contents (it being filesystem-agnostic and all). That worked, he
> told me. DosSetFilePtr() didn't return ERROR_SEEK.
FAT is a fallback IFS. And if it uses FSH_DOVOLIO() internally to access
a volume, it can work well. This is true for other IFSes as well as
FAT32.IFS.
BTW, I have a question. It can access to the area over 2GB or 4GB ?
> And Allan Holm has
> provided a useful datum, since he has managed to get things to work with
> the FAT32.IFS driver installed, but on a ~4GiB volume.
>
As I said the above.
Anyway, I did not release the 0.9.14 because it has not any enhancements
for end-users, but just for developers. In addition, FAT32.IFS already
has a good replacement for DASD IO.
And currently, DosWrite() does not work due to an Access Denied error.
What I said "I don't know what the cause is" is this.
Ilya Zakharevich
>>> * Raw access with DosRead/DosWrite/DosSetFilePtr works just fine on
>>> your ~4GiB FAT32 volume.
>> No. We know that it does not work OK.
> Yes, we know that it works OK when reading and writing whole disc
> sectors using the raw interface.
Do not you listen? It does not work OK in this situation.
> Allan has run CHKVOL all of the way
> through quite successfully, twice even, and sent me the log of its
> output as proof.
Who cares? So you know ONE situation when it did work successfully;
this proves nothing - expecially when I know one situation when it did not.
Ilya
Jonathan de Boyne Pollard
> some of the GPLed Linux JFS.
>
That's rather naughty.
Jonathan de Boyne Pollard
>> output as proof.
>>
> Do not you listen? It does not work OK in this situation.
>
I listen to the person who has run the program, seen it work, and sent
me the entire output log as proof. I tend not to listen so much to the
Ilya Zakharevichs of this world who then come along later and say that
what the two of us have seen with our own two eyes is impossible, and
cannot be so. When it's a choice between you making bald assertions on
Usenet and hard data in hand, M. Zakharevich, I go with the hard data in
hand.
You know, this is the second time in the past month or so when you've
tried to convince me of the impossibility of something that I have
myself either done directly or seen done by someone else.
Dave Yeo
Actually I should clarify that I think they used some of the GPLed code
as I don't have access to the newest code and I might be wrong. (plus
they might be offering the code to the people with the newest binaries)
Dave
Jonathan de Boyne Pollard
> enhancements for end-users, but just for developers.
>
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
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.
> In addition, FAT32.IFS already has a good replacement for DASD IO.
>
To think that that's a "good replacement" is entirely muddled. It's
neither good nor a replacement. We don't *want* filesystem-specific
replacements for a standard OS/2 4.5 mechanism. We want the
operating-system-supplied mechanism that the 4.5 Toolkit documents to
*work*. As the 4.5 Toolkit doco says, there's a "new" (for 1999)
mechanism for handily reading volumes without having to care what the
filesystem type is or perform *any* filesystem-specific gyrations. We
have, the Toolkit doco tells us, "common file system APIs" that provide
us with a "greatly simplified migration path for applications". (And it
*is* greatly simplified, there's no doubt about it.) It's entirely
backwards and muddled to work in the direction of "replacing" that with
something that requires undocumented you-have-to-be-in-on-the-secret
filesystem-specific gyrations. That's not improvement. That's going
backwards to the situation that existed before. Where "before" is
"before 1999", moreover.
Jonathan de Boyne Pollard
> structure is passed to an "L" function.)
>
Thanks to Dave Yeo, I've been able to check this out. The "L" functions
take the same sffsi structure, except that it has two 64-bit fields
tacked on to the end: sfi_sizel and sfi_positionl. Obviously, by their
names, these replace the 32-bit sfi_size and sfi_position fields earlier
in the structure. Quite how the kernel tells which set of fields, the
32-bit ones or the 64-bit ones, an IFS driver is maintaining is
unclear. I see no sign of JFS setting a flag to tell the kernel which
fields it is maintaining, and it maintains the 64-bit fields, and *only*
the 64-bit fields, even in the non-"L" entrypoints. (The non-"L"
entrypoints simply call the "L" ones. Perhaps this is a JFS bug. Have
there been reports of the 2003 JFS.IFS not working on OS/2 prior to
version 4.5? The 4.0 and earlier kernels will be expecting the 32-bit
fields to be maintained. They probably won't even be allocating the
extra space for the 64-bit ones.)
Steve Wendt
>>> As far as I know the newer JFS is closed source even though they used
>>> some of the GPLed Linux JFS.
>
> Actually I should clarify that I think they used some of the GPLed code
> as I don't have access to the newest code and I might be wrong.
What else could they have possibly used, unless IBM provided them with
source code under another license? The likelihood of the latter is
pretty much zero.
Allan
ECS's JFS code is based directly off the OpenJFS code, that is available
on Netlabs FTP. OpenJFS is GPL, and so Mensys have to respect that,
and I'm sure they will; but they may not have thought about it.
That said, the Bootable JFS part may not be opensource, as it is not
part of IFS driver, it is a separate piece of software, that Mensys have
made by themselves.
For people still using old Warp - osFree's FreeLDR can boot on (IBM)JFS :-)
FAT32 source code is available at svn in Netlabs.
Allan
> > (I suggest that those with JFS source code access check what SFFSI
> > structure is passed to an "L" function.)
> >
>
> Thanks to Dave Yeo, I've been able to check this out. The "L" functions
> take the same sffsi structure, except that it has two 64-bit fields
> tacked on to the end: sfi_sizel and sfi_positionl. Obviously, by their
> names, these replace the 32-bit sfi_size and sfi_position fields earlier
> in the structure. Quite how the kernel tells which set of fields, the
> 32-bit ones or the 64-bit ones, an IFS driver is maintaining is
> unclear. I see no sign of JFS setting a flag to tell the kernel which
> fields it is maintaining, and it maintains the 64-bit fields, and *only*
> the 64-bit fields, even in the non-"L" entrypoints. (The non-"L"
> entrypoints simply call the "L" ones. Perhaps this is a JFS bug. Have
> there been reports of the 2003 JFS.IFS not working on OS/2 prior to
> version 4.5?
JFS came with WSEB - aka OS/2 4.5
JFS have never been designed to work with prior kernels.
A.D. Fundum
All licenses are bogus (/"unfinished"). What makes one think that a
license, if a.o. legal at all, written in e.g. Japanese (or English),
applies to people not being to read Japanese (or English)?!
> and I'm sure they will
In this case, the only reason in Netherland (just one land) to look at
a foreign piece of strange text is most likely the fact that they're
supposed to be a professional business. But that's easy to avoid, and
this "respect" (with Mensys having and excellent track record indeed)
has nothing to do with any license at all.
Of course there's x:\PROGRAMS\NETSCAPE\PROGRAM\LICENSES\LICENSE.SV to
solve the translation problem. The license still is bogus
("/unfinished"), but I'm afraid PROGRAMS isn't a Swedish word. Nor are
PROGRAM, LICENSES and LICENSE. No reason to look for this file, no
need to read it, no record of having read it, no record of each user
having agreed to this license, no problem using Netscape without
having read it, and so on. Perhaps the only real protection is a brand
name, e.g. the "NETSCAPE"-part.
--
Jonathan de Boyne Pollard
>> JFS bug. Have there been reports of the 2003 JFS.IFS not working on
>> expecting the 32-bit fields to be maintained. They probably won't
>> even be allocating the extra space for the 64-bit ones.)
>>
> JFS have never been designed to work with prior kernels.
>
it. The question is whether that someone experienced problems.
KO Myung-Hun
Jonathan de Boyne Pollard wrote:
>> Anyway, I did not release the 0.9.14 because it has not any
>> enhancements for end-users, but just for developers.
>>
>
> 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 ?
Oh, amazing. ^____^
Your end users seem to have very powerful ability. BTW, I call them
developers.
> 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.
As I said before, the cause is 'overflow' of a 32bit size variable. You
don't understand ?
And do you think that I committed the changeset to the public repository
without any checking ? Please stop kidding...
If you read the changeset carefully, you could know that it enabled DASD
IO only if the volume size is less than 2GB. Otherwise, any Read/Write
request encounters 'Access Denied' until a user change the io mode of
FAT32 to sector io one explicitly.
Finally, of course, I have the binary that you're saying
'not-for-end-users FAT32.IFS'.
I don't understand the reason why you would not believe the changeset of
the public repository.
>> In addition, FAT32.IFS already has a good replacement for DASD IO.
>>
>
> To think that that's a "good replacement" is entirely muddled. It's
> neither good nor a replacement. We don't *want* filesystem-specific
> replacements for a standard OS/2 4.5 mechanism. We want the
> operating-system-supplied mechanism that the 4.5 Toolkit documents to
> *work*. As the 4.5 Toolkit doco says, there's a "new" (for 1999)
> mechanism for handily reading volumes without having to care what the
> filesystem type is or perform *any* filesystem-specific gyrations. We
> have, the Toolkit doco tells us, "common file system APIs" that provide
> us with a "greatly simplified migration path for applications". (And it
> *is* greatly simplified, there's no doubt about it.) It's entirely
> backwards and muddled to work in the direction of "replacing" that with
> something that requires undocumented you-have-to-be-in-on-the-secret
> filesystem-specific gyrations. That's not improvement. That's going
> backwards to the situation that existed before. Where "before" is
> "before 1999", moreover.
>
Hmmm... Why should OS/2 v4.5 be the standard ? I hope that FAT32.IFS can
be used on Warp4 and Warp3 if possible. In addition, I love the backward
compatibility of OS/2. BTW what do you mean by 'new' mechanism ? "L"
APIs ? Or just DosOpen()/DosRead()/DosWrite()/DosSetFilePtr()/DosClose()
APIs ? DASD access using Dos APIs is a traditional way not new from OS/2
v4.5.
And what do you think about FAT and HPFS ? Do they satisfy your needs ?
I can say that they also will not work with Dos APIs on the area over
4GB of those partitions.
I think that you don't understand what is a replacement and is a
improvement. Ok. Let's call it the difference of point of view.
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.
However, I know, Lars had a plan to support "L" entry points. But I
don't know the result. 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. For the volume bigger than 2GB, the sector io
should be set.
I say once more. If you think the ways of FAT32.IFS are not good, just
do not use them.
I don't want to waste my time to useless debates.
Anonymous
> > OpenJFS is GPL, and so Mensys have to respect that,
I don't know the history but /I believe/ IBM wrote JFS for AIX OS and it was
then ported by IBM to OS/2. It seems like there are at least 2 branches of
JFS IBM is involved with and /maybe/ one additional one that's GPL.
Alex Taylor
The Linux JFS was IIRC ported directly from the OS/2 JFS source code,
which IBM did originally release about 10 years ago. It was on an IBM
site (AlphaWorks, I think) as was the LVM source; I think both have
disappeared from there now, though.
The modified eCS JFS has its source code released (in snapshots)
somewhat fitfully via FTP at ftp.netlabs.org/pub/openjfs (currently
it's a couple of releases out of date); if there's a more current
repository I'm not sure where it is. The latest source should be
available on request, though.
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.
A.D. Fundum
Right, it isn't. There sure is a GA-gap between Warp 4 (at best FP9,
but FP5 is more common) and eCS. Anything in that gap doesn't qualify
as a standard, and perhaps shouldn't be printed on a box as a
requirement. Requiring v4.5 may be techically true, but that doesn't
make it a standard.
--
Dave Yeo
IBM rewrote JFS for OS/2, then ported it to AIX and branched it to the
GPL version for Linux.
Dave
Lars Erdmann
It's not just adding an additional entry point.
The "L" variants are called as 32-bit entry points whereas the old filesystem APIs are called as 16-bit entry points.
There are a bunch of other implications where most of these deal with improving throughput (for example using the
flat 32-bit strat3 entry point of OS2DASD.DMD/OS2LVM.DMD instead of the old 16-bit strat2 entry point).
On the other hand, while the kernel splits DosRead/DosWrite transfer into chunks of 64k for the old 16-bit filesystems
the new entry points can swallow up to 4 GB passed on one invocation of DosRead/DosWrite.
The bottom line is: the "> 2 GB extension" is a messy addon which is at best documented in JFS.IFS source code.
The design is horrible and you have to introduce a thunking layer to properly handle the mixture of 32-bit and
16-bit entry points. What's more, you can no longer use the (16-bit) filesystem helpers or if you want to use them,
you need to thunk from 32-bit to 16-bit, call them and thunk back to 32-bit.
Have a look at the OS/2 OpenJFS source code and you will see what I mean.
The OpenJFS source code used to be available as a Netlabs CVS archive, Adrian Gschwend from Netlabs has zipped it up
directly from the CVS source tree:
ftp://ftp.netlabs.org/pub/openjfs/openjfs-20070128203903.zip
If you want to step forward, ask Adrian Gschwend to convert this thing into an SVN repository (and with Trac view
support).
Lars
Jonathan de Boyne Pollard
> APIs, you basically have to rewrite FAT32.IFS.
>
That's complete twaddle. The code that I posted earlier is, if one
changes sfi_size/sfi_pointer to sfi_sizel/sfi_pointerl, pretty much all
that one has to have.
> It's not just adding an additional entry point.
>
That's exactly what it is. Rewriting FAT32.IFS would be necessary for a
complete change of implementation strategy or a major change in
interface architecture (such as, say, changing to a Windows NT IFS where
everything is an IORP), which simply implementing a couple of shims to
map a 64-bit integer parameter into a 32-bit integer parameter, keeping
the semantics as they stand, is not.
> The "L" variants are called as 32-bit entry points whereas the old
> filesystem APIs are called as 16-bit entry points.
>
The "L" does not denote bitness. The "32" denotes bitness. There are
16-bit and 32-bit flavours of "L" and non-"L". I already pointed out
that the VirtualBox shared folders IFS implements 3 out of the 4
possible combinations. I even gave you the four function names. I've
also checked and reported the names of the "new" (i.e. 1999, again)
64-bit fields of the system file table entry that the "L" entrypoints
are expected to manage.
A.D. Fundum
> I don't know the history but /I believe/ IBM wrote JFS for AIX OS
> and it was then ported by IBM to OS/2. It seems like there are
> at least 2 branches of JFS IBM is involved with and /maybe/
> one additional one that's GPL.
As Dave already mentioned, there's a GPL one. Which means that at
least that version is actually "donated to the public domain". For one
because a GPL written in English, if relevant at all (it isn't), isn't
valid in many, many countries where English is not a(n official)
language, and there's no reason at all to assume/know the product
isn't free (I know eCS isn't free, no matter what an irrelevant
license reads). Please note a professional Dutch company, like Mensys
is, has to perform more checks than private people because they're
supposed to act professional.
If you want a GPL to be valid for Dutch people, it at least has to be
written in an official language (Dutch, or perhaps West Frisian in a
small area of Netherland). Now it's like some programmer from Japan,
with no knowledge of any other language, wants to concur the world
with the made-up requirement (in Japanese) "Must send me postcard,
otherwise delete software". Why do people think that this is valid for
French people in France, not being able to speak Japanase?! It isn't.
Obviously. No need to hire a Japanese interpreter, hopefully not
expericiening the Paris Syndrome.
Appearantly there's a GPL version of JFS, so a version is actually
"donated to the public domain". Unconditionally. If English is your
official language and you think the GPL is perfectly valid (no, it
isn't), all it may take is a person in a non-English speaking country
to avoid this "problem". Nevertheless "respect" is an important word
here, but IRL a GPL doesn't exist. The American "Free Software
Foundation", not having any relation with me, does make things up.
--
Andy
wrote:
> Anyway, I did not release the 0.9.14 because it has not any enhancements
> for end-users, but just for developers. In addition, FAT32.IFS already
> has a good replacement for DASD IO.
> And currently, DosWrite() does not work due to an Access Denied error.
> What I said "I don't know what the cause is" is this.
>
I just pulled the code from svn, unfortunately there are no bldlevel
strings so at first I didn't realize this but the trunk built 0.9.11.
I don't see a 0.9.14 tag, what do I need to pull for 0.9.14?
Chkdsk shows (UFAT32.DLL version 0.9.11 compiled on Apr 05 2011) is
how I determined the build level.
Andy
--
Allan
Looks like the 'branches' version are more complete and uptodate.
Jonathan de Boyne Pollard
>> foolish that may be; that's its prerogative. But you're trying to
>> have your cake and eat it. You're trying to argue that there's a
>> possibility that the listing is not legitimate in the same breath as
>> you're trying to argue that all listings are in accordance with what
>> the WWW page says because listings are only ever made legitimately.
>> You cannot have both at the same time. The Clue which is not
>> percolating through to you, that you're risibly trying to paint as
>> inexperience, is that *the WWW page isn't necessarily the truth*.
>>
> No, I'm trying to keep you honest. Claiming "unknown reason" when they
> gave a reason is dishonest. If you don't believe them then the honest
> thing to write would be something along the lines of "a reason fro
> which they provide no raw data.
>
> You're lying about what I wrote.
>
> I never suggest that you knew any part of the reason; what I suggested
> was that you should have known the reason that they gave and that the
> use of the term "unknow reason" implies that they didn't give a reason.
>
We can see that the *only* person trying to rewrite what you wrote to
try and make it mean something else is you. We can also see that you're
now desperately tap-dancing and doing the usual Usenet silly dances when
one is blatantly wrong. You "never suggest[ed] that [I] knew any part
of the reason" but you "tried to keep [me] honest" by disputing my
therefore calling it an unknown reason? I think that the sheer
foolishness of your notions here speak for themselves to the world. I
certainly regard them as ludicrous. "You don't know the reason but you
cannot use the word unknown to say that.", indeed! What utter
bilgewater you are propounding in the name of trying to save face.
Jonathan de Boyne Pollard
> which IBM did originally release about 10 years ago. It was on an IBM
> site (AlphaWorks, I think) as was the LVM source; I think both have
> disappeared from there now, though.
>
That's one of the little-spoken-of problems in the world of open
source. Years down the line, it turns out that things aren't open
source, because the source isn't published any more. The JFS project at
SourceForge has only Linux trees (linux24, linux25, and linux-2.2.12)
and there's no sign of those trees ever having had a jfs_ifs.c file
(which is the file to look at for the relevant OS/2 FSD entrypoints, if
anyone comes across this discussion in the future).
OS/2 LVM source code was available? What was it the source for? The
LVM utility? The device manager driver? I've looked all over the place
to find a description of the on-disc data structures, so far fruitlessly.
> The modified eCS JFS has its source code released (in snapshots)
> somewhat fitfully via FTP at ftp.netlabs.org/pub/openjfs (currently
> it's a couple of releases out of date); if there's a more current
> repository I'm not sure where it is. The latest source should be
> available on request, though.
>
I went to the list at http://svn.netlabs.org/ . As you can see, there's
no mention there. A request to whom?
Andy
wrote:
> On Tue, 5 Apr 2011 15:42:03 UTC, "Andy" <nospam-abwil...@nospam-gmail.com> wrote:
>
> > On Sun, 3 Apr 2011 05:51:23 UTC, KO Myung-Hun <ko...@chollian.net>
> > wrote:
> >
> > > Anyway, I did not release the 0.9.14 because it has not any enhancements
> > > for end-users, but just for developers. In addition, FAT32.IFS already
> > > has a good replacement for DASD IO.
> > > And currently, DosWrite() does not work due to an Access Denied error.
> > > What I said "I don't know what the cause is" is this.
> > >
> >
> > I just pulled the code from svn, unfortunately there are no bldlevel
> > strings so at first I didn't realize this but the trunk built 0.9.11.
> > I don't see a 0.9.14 tag, what do I need to pull for 0.9.14?
> > Chkdsk shows (UFAT32.DLL version 0.9.11 compiled on Apr 05 2011) is
> > how I determined the build level.
>
> Looks like the 'branches' version are more complete and uptodate.
>
OK, branches does seem more uptodate (I am still used to thinking CVS
where Trunk is the most uptodate testing stuff). However, it is still
showing as 0.9.13 and not the 0.9.14, not sure if that is cosmetic or
if I still haven't found the latest code.
Andy
--
Allan
> > > I just pulled the code from svn, unfortunately there are no bldlevel
> > > strings so at first I didn't realize this but the trunk built 0.9.11.
> > > I don't see a 0.9.14 tag, what do I need to pull for 0.9.14?
> > > Chkdsk shows (UFAT32.DLL version 0.9.11 compiled on Apr 05 2011) is
> > > how I determined the build level.
> >
> > Looks like the 'branches' version are more complete and uptodate.
> >
> OK, branches does seem more uptodate (I am still used to thinking CVS
> where Trunk is the most uptodate testing stuff). However, it is still
> showing as 0.9.13 and not the 0.9.14, not sure if that is cosmetic or
> if I still haven't found the latest code.
There is no newer code in svn, according to trac.
Wiki for FAT32 recommends fetching trunk too - but if you look around
in TRAC and looks at the revisions, you can easily see, that trunk is
missing some of the latest revision done before 0.9.13
0.9.14 - well, it isn't released yet, isn't it ? So obviously, there is no such
version - not even in svn. Updating the version number/bldlevel is the
last thing you do, before putting out a new public version.
Dave Yeo
> Appearantly there's a GPL version of JFS, so a version is actually
> "donated to the public domain".
It doesn't work like that under the Berne convention which most
countries are signatories to.
The GPL is a licence to use a copyrighted work and if the GPL is invalid
for any reason such as the language it is written in then it falls under
the default copyright, not public domain.
Dave
Dave Yeo
>> which IBM did originally release about 10 years ago. It was on an IBM
>> site (AlphaWorks, I think) as was the LVM source; I think both have
>> disappeared from there now, though.
>>
>
> That's one of the little-spoken-of problems in the world of open
> source. Years down the line, it turns out that things aren't open
> source, because the source isn't published any more. The JFS project at
> SourceForge has only Linux trees (linux24, linux25, and linux-2.2.12)
> and there's no sign of those trees ever having had a jfs_ifs.c file
> (which is the file to look at for the relevant OS/2 FSD entrypoints, if
> anyone comes across this discussion in the future).
I remember looking at one of the first Linux releases of JFS. There were
lots of #ifdef __OS2__ but I don't think there was a jfs_ifs.c file and
knowing IBM I doubt that they would have released one.
Should be able to look at the svn history at sourceforge to find the
first release.
Dave
Andy
wrote:
> Jonathan de Boyne Pollard wrote:
The OS/2 specific code (at least some of it such as DASD support) was
removed by the maintainers but was initially released (not sure of the
jfs_ifs.c).
Andy
--
Andy
wrote:
I took KO's mention of 0.9.14 to mean the code was there just not
released as binary.
Andy
--
Lars Erdmann
with you any longer.