Found an EA bug??? - OS2

This is a discussion on Found an EA bug??? - OS2 ; Hi, I have been working extensively with EAs in the past few weeks. *yuck* In any case I have found that I can read and write them with no problems at all. So as part of this I have written ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Found an EA bug???

  1. Found an EA bug???

    Hi,

    I have been working extensively with EAs in the past few weeks. *yuck*
    In any case I have found that I can read and write them with no
    problems at all. So as part of this I have written a test suite which
    thoroughly exercises reading and writing EAs. So far, it's working
    great. But...


    It seems, however that the .KEYPHRASES field on the standard notebook
    is not written correctly. If I set it in the notebook or
    programmatically then try to read it I get an error that the "EA list
    is inconsistent". No other standard or custom EA I read and write does
    this. I am using ECS 1.1 which has a customized version of XWorkplace,
    right? Could that be the issue?

    Anyone else find this to be the case?
    Cheers,

    Jeff

    write me directly at jgaynor at jqhome dot net


  2. Re: Found an EA bug???

    On Wed, 26 Jan 2005 16:42:39 UTC, spam@jqhome.net wrote:

    > It seems, however that the .KEYPHRASES field on the standard notebook
    > is not written correctly. If I set it in the notebook or
    > programmatically then try to read it I get an error that the "EA list
    > is inconsistent". No other standard or custom EA I read and write does
    > this. I am using ECS 1.1 which has a customized version of XWorkplace,
    > right? Could that be the issue?
    >
    > Anyone else find this to be the case?


    Nope. I added some keyphrases to a file that already had 3 other EAs
    using its eWP-modified file page. I then looked at the result using
    Henk Kelder's eabrowse, along with a couple of REXX scripts I'd written
    to enumerate EAs & to list their values. None of these reported any
    problems, and each displayed the values correctly.

    FWIW....KEYPHRASES is a multi-valued, multi-typed attribute; each
    value is of type EAT_ASCII. The notebook uses linefeeds to delimit
    the individual values. Could this be a parsing error in your code?


    --
    == == almost usable email address: rich AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  3. Re: Found an EA bug???

    Hi Rich!

    [.KEYPHRASES is documented as multi-valued single-typed and no EAs use
    linefeeds internally. To save space, they use two bytes to count length
    rather than one for null termination. Go figger...]

    Here is the rub, using

    cmd.exe /c type -ea:FILENAME

    I can view the EAs fine. The format in the documentation for an
    EAT-MVST states that it is of the form

    EAT_MVST codepage count type length data length data ...

    EAT_MVMT codepage count type length data type length data ...

    ( so these have two more bytes for the type with each entry)

    so for example this is what we expect

    EAT_MVST 0 04 EAT_ASCII 05 HELLO
    03 FOO
    05 FNORD

    What I actually see is that the type is repeated with each of these, so

    EAT_MVST 0 04 EAT_ASCII 05 HELLO
    EAT_ASCII 03 FOO
    EAT_ASCII 05 FNORD

    and the command line tool shows that it *expects* those two type bytes
    for each field, making this identical to the format of and EAT_MVMT.
    When I parse it that way, things seem ok.

    So I guess the question is this: Do people just know to do it that way
    and I should go with observed vs. documented? Is this an open secret?

    Man I hate the EA API... But I've gotten much better at abstruse
    pointer arithmetic!

    Jeff


  4. Re: Found an EA bug???

    On Wed, 26 Jan 2005 18:25:28 UTC, spam@jqhome.net wrote:

    > [.KEYPHRASES is documented as multi-valued single-typed


    So it is...

    > and no EAs use linefeeds internally.


    I only meant that the notebook code uses linefeeds to delimit individual
    values. As you know, they aren't preserved in the EA.

    > To save space, they use two bytes to count length rather than one for
    > null termination. Go figger...]


    It's much quicker if you know where the string ends rather than having
    to search for it. In any case, null-termination is a C invention while
    EAs were clearly designed by someone who had been writing in assembler
    for 20 years :-)

    > Here is the rub, using
    >
    > cmd.exe /c type -ea:FILENAME


    Wow! I didn't know such a command existed.

    [discussion of documentation vs empirical evidence snipped]

    > So I guess the question is this: Do people just know to do it that way
    > and I should go with observed vs. documented? Is this an open secret?


    Documentation is only a starting point. When empirical evidence
    contradicts it, either you didn't understand the docs or the docs
    are just wrong. It's for you to decide in any particular case, but
    the general consensus is: when in doubt, blame the docs.

    In the example you gave, the util displays the name but pays it no
    heed. Rather it looks at the EAT_ value and parses it accordingly.
    If you're only reading EAs, you should do likewise and "go with the
    flow". OTOH, if you're writing them you may have to be a bit more
    rigorous. For that, use the evidence you've accumulated: if every
    ..KEYPHRASES you've seen is EAT_MVMT, yours should be too.

    BTW... if you suspect eWP is the reason why the docs are out of sync
    with reality, boot to a commandline, then rename \ecs\system\ewps.
    When you reboot you'll be able to test against a generic WPS. If
    the plain-vanilla notebook still turns out MVMT keyphrases, then the
    docs are wrong.

    > Man I hate the EA API... But I've gotten much better at abstruse
    > pointer arithmetic!


    I feel your pain :-)


    --
    == == almost usable email address: rich AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  5. Re: Found an EA bug???

    >>To save space, they use two bytes to count length rather than one for
    >>null termination. Go figger...]

    >
    > It's much quicker if you know where the string ends rather than having
    > to search for it. In any case, null-termination is a C invention while
    > EAs were clearly designed by someone who had been writing in assembler
    > for 20 years :-)


    I wasn't around when these APIs were coded; however, there is another
    reason to choose a character array preceded by a length field: It makes
    it much easier to read it out of the file! You read the length and know
    how much memory to allocate, rather than doing a read and copy.

  6. Re: Found an EA bug???

    Scott G. wrote:
    >>> To save space, they use two bytes to count length rather than one for
    >>> null termination. Go figger...]

    >>
    >>
    >> It's much quicker if you know where the string ends rather than having
    >> to search for it. In any case, null-termination is a C invention while
    >> EAs were clearly designed by someone who had been writing in assembler
    >> for 20 years :-)

    >
    >
    > I wasn't around when these APIs were coded; however, there is another
    > reason to choose a character array preceded by a length field: It makes
    > it much easier to read it out of the file! You read the length and know
    > how much memory to allocate, rather than doing a read and copy.


    Gee soundslike the days of SDF in EXEC 8 (that is UNIVAC 1100 for you
    yung'uns)

  7. Re: Found an EA bug???

    Here in comp.os.os2.programmer.misc,
    Leo Tick spake unto us, saying:

    >Scott G. wrote:
    >
    >> I wasn't around when these APIs were coded; however, there is another
    >> reason to choose a character array preceded by a length field: It makes
    >> it much easier to read it out of the file! You read the length and know
    >> how much memory to allocate, rather than doing a read and copy.

    >
    >Gee soundslike the days of SDF in EXEC 8 (that is UNIVAC 1100 for you
    >yung'uns)


    And Unisys OS2200 for those of us who are still current users. :-)

    @FIN
    $$CLOSE

    --
    -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Smyrna, GA USA
    OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
    WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
    The Theorem Theorem: If If, Then Then.

+ Reply to Thread