Optional element in OS4 AnchorPath

[xenic]

The OS4 AnchorPath structure has an element defined like this:

struct ExamineData * ap_ExData; /* Ptr to optional ExamineData */

The word "optional" makes it sound like the ap_ExData element will only be present under certain conditions or that some flag must be set to assure it's presence. Before I start using the AnchorPath ap_ExData element, I'd like to know if a program can rely on that element being present or what flag I might need to set to assure it's presence? Also, are ap_Info & ap_ExData elements mutually exclusive or will both elements contain valid data??

[colinw]

The OS4 AnchorPath structure has an element defined like this:

struct ExamineData * ap_ExData; /* Ptr to optional ExamineData */

The word "optional" makes it sound like the ap_ExData element will only be present under certain conditions or that some flag must be set to assure it's presence. Before I start using the AnchorPath ap_ExData element, I'd like to know if a program can rely on that element being present or what flag I might need to set to assure it's presence? Also, are ap_Info & ap_ExData elements mutually exclusive or will both elements contain valid data??

Both will be available when the pointer is non-null. (the FIB can have truncated file size and short name fields when appropriate),
as I have to maintain the old structure for backward compatibility for older code.

There are no control flags for the ap_ExData, it's simply a situation where I havn't finished updating those functions yet,
as they are used mainly by the C: commands, they are low on my list of things to do and the C: commands are working well at the moment.
You may be better just using an ExamineDir() loop with a patterm matching hook.

However, if you have your heart set on using MatchFirst()/MatchNext() then you may use the following code to get access to 64 bit file sizes
until such time as I can get around to updating these old functions.

Code: Select all

static int64 get_size64_from_anchor(struct AnchorPath *ap)
{
    int64 size64;
    struct ExamineData *exd;
    APTR old_window_pointer;
    BPTR old_dir;

    if (ap->ap_ExData != NULL)
    {
        size64 = ap->ap_ExData->FileSize;
    }
    else
    {
        size64 = (int64)ap->ap_Info.fib_Size;
  
        old_window_pointer = SetProcWindow((APTR)-1);
        old_dir = SetCurrentDir(ap->ap_Current->an_Lock);
        exd = ExamineObjectTags( EX_StringNameInput, ap->ap_Info.fib_FileName, TAG_END);
        SetCurrentDir(old_dir);

        if (exd != NULL)
        {
            size64 = exd->FileSize;
            FreeDosObject(DOS_EXAMINEDATA, exd);
        }
        SetProcWindow(old_window_pointer);
    }

    if (size64 < 0)
        size64 = 0;  /* don't return -1 for others */

    return(size64);
}

You may also choose to add long name support to the above function too, if you wish to go that way.

[xenic]

@colinw

There are no control flags for the ap_ExData, it's simply a situation where I havn't finished updating those functions yet,

We're currently using the old AnchorPath structure but if we could rely on getting an ap_ExData I was going to switch to the new AnchorPath structure. As it is, it's easier to maintain compatability with other platforms by using the old AnchorPath structure. We're already using ExamineObject() (as in your example) to get the 64 bit size. We'll wait until the new AnchorPath ap_ExData is reliable before switching.

Thanks for responding and clearing up the issue.

[tboeckel]

We'll wait until the new AnchorPath ap_ExData is reliable before switching.

What are you waiting for? It already is reliable. If it is non-NULL then you can use ap_ExData and take all required information from the supplied structure. Otherwise you take all the required information from the old AnchorPath structure. I really don't understand your trouble.

[xenic]

@tboeckel
If you read Colin's reply and the example he provided, it means ap_ExData can be NULL but you can get the size by calling ExamineObject(). If ap_ExData can be NULL but ExamineObject() can get the size, that means ap_ExData is unreliable and not worth using at this point. If I wrote a function that sometimes didn't work and had to use another function to get the required data, why would I bother with the first function? I would use the second function and get rid of the first.

[salass00]

@tboeckel
If you read Colin's reply and the example he provided, it means ap_ExData can be NULL but you can get the size by calling ExamineObject(). If ap_ExData can be NULL but ExamineObject() can get the size, that means ap_ExData is unreliable and not worth using at this point. If I wrote a function that sometimes didn't work and had to use another function to get the required data, why would I bother with the first function? I would use the second function and get rid of the first.

Because getting the file size from ap_ExData if it's available is much more efficient than doing an additional ExamineObject() and it doesn't take much more code as shown by Colin.

[xenic]

Because getting the file size from ap_ExData if it's available is much more efficient than doing an additional ExamineObject() and it doesn't take much more code as shown by Colin.

I'm in the process of trying the new AnchorPath but have some issues to resolve.