[comp.sys.amiga.programmer] Question About FileInfoBlock Structures

ernie@aquarium.buffalo.ny.us (Ernest J. Gainey III) (02/04/91)

Hello Everyone,

 I'm curious if anyone knows why this little bit of code produces such
 a strange result, from what I can tell, it should do a directory
 listing filename, filesize, and protections...

 Problem is... the fib_Protection field of the FileInfoBlock structure
 is Empty... when I print it as a "%d", i get a 0... all the other fields
 appear to have values... but do a...
  printf("Protection==%d\n",MyFileInfoBlock->fib_Protection);
 and I get a: Protection==0 ...

Here, I'll include my little test program, and show ya... and maybe someone
can figure out whats wrong...

----------------------- Cut Here Please :) --------------------------------
#include <dos.h>
#include <proto/dos.h>
#include <proto/exec.h>
#include <exec/memory.h>

VOID
DisplayFile(struct FileInfoBlock *MyFileInfoBlock)
{
 char Protection[9];
 int x;
 int Prot;

 static char *ProtectionNames[]=
  { "d","e","w","r","a","p","s"};

 bzero(Protection,sizeof(Protection));

 for (x=6; x>=0; x--)
 {
  if (MyFileInfoBlock->fib_Protection && (1<<x))
   {
    Protection[6-x]=*ProtectionNames[x];
   }
    else
   {
    Protection[6-x]='-';
   }
}

 printf("%-20s ",MyFileInfoBlock->fib_FileName);
 if (MyFileInfoBlock->fib_DirEntryType>0)
  {
   printf("%6s ","Dir");
  }
   else
  {
   printf("%6d ",MyFileInfoBlock->fib_Size);
  }
  printf("%s\n",Protection);

}

main(argc,argv)
 int argc;
 char *argv[];
{

  BPTR MyLock;
  struct FileInfoBlock *MyFileInfoBlock;
  int Success;

  if(!(MyFileInfoBlock=AllocMem(sizeof(struct FileInfoBlock),MEMF_PUBLIC)))
   {
    printf("Error Allocating FileInfoBlock\n");
    exit(1);
   }

  if (argc<2)
   {
    MyLock=Lock("",ACCESS_READ);
   }
    else
   {
    MyLock=Lock(argv[1],ACCESS_READ);
   }

   if (MyLock==NULL)
    {
     printf("Error Achieving Lock\n");
     exit(2);
    }

  Success=Examine(MyLock,MyFileInfoBlock);
  if (Success) DisplayFile(MyFileInfoBlock);

  do
   {
    Success=ExNext(MyLock,MyFileInfoBlock);
    if (Success) DisplayFile(MyFileInfoBlock);
  } while (Success);

  UnLock(MyLock);
  FreeMem(MyFileInfoBlock,sizeof(struct FileInfoBlock));

}

------------------ EOF -- Cut Here ----------------------------------------

Heres an example of the output:

work			Dir -------
dir.c		       1443 -------
dir		       6140 -------
test			  0 -------

Thanks all for your help...

Ernest J. Gainey III   Home: ernie@aquarium.buffalo.ny.us        //\\
 The Amiga Aquarium  School:  gainey03@snybufva.bitnet          //==\\
  +1 716 999-9999    Snail :61 Tarkington,Tonawanda,NY 14150 \\//    \\miga!

jap@convex.cl.msu.edu (Joe Porkka) (02/05/91)

ernie@aquarium.buffalo.ny.us (Ernest J. Gainey III) writes:

>Hello Everyone,

> I'm curious if anyone knows why this little bit of code produces such
> a strange result, from what I can tell, it should do a directory
> listing filename, filesize, and protections...

> Problem is... the fib_Protection field of the FileInfoBlock structure
> is Empty... when I print it as a "%d", i get a 0... all the other fields
> appear to have values... but do a...
>  printf("Protection==%d\n",MyFileInfoBlock->fib_Protection);
> and I get a: Protection==0 ...

Thats becuase the RWED bits are inversed. If C:LIST reports that the
'A' and the 'R' flags are set, then in fib_Protection, the bit
corresponding to 'a' == 1, and the bit for 'r' ==0.

So, try (fib_Protection ^ 0x0f). That is, reinvert the sense of
those last bit.


The reason this is: The default for protection bits is ----RWED, which
cooresponds to fib_Protection==0

jesup@cbmvax.commodore.com (Randell Jesup) (02/05/91)

In article <18a052ee.ARN02d3@aquarium.buffalo.ny.us> ernie@aquarium.buffalo.ny.us writes:
> Problem is... the fib_Protection field of the FileInfoBlock structure
> is Empty... when I print it as a "%d", i get a 0... all the other fields
> appear to have values... but do a...
>  printf("Protection==%d\n",MyFileInfoBlock->fib_Protection);
> and I get a: Protection==0 ...

	Simple: the first 4 bits (rwed) are true is the bit is 0.  So 0
means -----rwed.  The others are true if non-zero.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)

bombadil@diku.dk (Kristian Nielsen) (02/05/91)

ernie@aquarium.buffalo.ny.us (Ernest J. Gainey III) writes:

>Hello Everyone,

> I'm curious if anyone knows why this little bit of code produces such
> a strange result, from what I can tell, it should do a directory
> listing filename, filesize, and protections...

> Problem is... the fib_Protection field of the FileInfoBlock structure
> is Empty... when I print it as a "%d", i get a 0... all the other fields
> appear to have values... but do a...
>  printf("Protection==%d\n",MyFileInfoBlock->fib_Protection);
> and I get a: Protection==0 ...

>Here, I'll include my little test program, and show ya... and maybe someone
>can figure out whats wrong...

[...]

> for (x=6; x>=0; x--)
> {
>  if (MyFileInfoBlock->fib_Protection && (1<<x))
                                       ^^
                                       ||
In addition to the comment someone made that some bits are inverted, this
line seems to be able to bring troubles also. The problem is, you are using
the logical and '&&', not the bitwise and '&'. So, (1 && 2)==1, while 
(1 & 2)==0, which was what you desired. Guess this is an example of why
these Pascal-folks hate C so much, while us hardened C-folks find it to bee
no prob.. ehh - never mind...

>   {
>    Protection[6-x]=*ProtectionNames[x];
>   }
>    else
>   {
>    Protection[6-x]='-';
>   }
>}

[...]

>Thanks all for your help...


	Kristian

==========================================================================
Kristian Nielsen                          |      ///   Only the AMIGA
Student at DIKU, University of Copenhagen |     ///
(Department of Computer Science)          | \\\///     makes it possible!
Denmark                                   |  \XX/
==========================================================================

dac@prolix.ccadfa.oz.au (Andrew Clayton) (02/05/91)

In article <18a052ee.ARN02d3@aquarium.buffalo.ny.us>, Ernest J. Gainey III writes:

>  I'm curious if anyone knows why this little bit of code produces such
>  a strange result, from what I can tell, it should do a directory
>  listing filename, filesize, and protections...

I'm just learning C, so this may be completely incorrect, but...

>  char Protection[9];
>  int x;
>  int Prot;
> 
>  static char *ProtectionNames[]=
>   { "d","e","w","r","a","p","s"};

I thought that STRINGS were delimited by doubt quotes and
CONSTANTS by single quotes, therefore your line should be:

  { 'd','e','w','r','a','p','s'};

Perhaps?

Dac
--

phil@adam.adelaide.edu.au (Phil Kernick) (02/06/91)

ernie@aquarium.buffalo.ny.us (Ernest J. Gainey III) writes:

>Hello Everyone,

> I'm curious if anyone knows why this little bit of code produces such
> a strange result, from what I can tell, it should do a directory
> listing filename, filesize, and protections...

> Problem is... the fib_Protection field of the FileInfoBlock structure
> is Empty... when I print it as a "%d", i get a 0... all the other fields
> appear to have values... but do a...
>  printf("Protection==%d\n",MyFileInfoBlock->fib_Protection);
> and I get a: Protection==0 ...

This one bit me too.  The answer is as follows...

    Protection bits     Sense
    ---------------     -----
        R                 0
        W                 0
        E                 0
        D                 0
        A                 1
        P                 1
        S                 1
        H                 1

This means that if fib_Protection returns 0 then the file has:
        ----RWED

If it had fib_Protection == 0xff then the file has:
        HSPA----

If it has fib_Protection == 0xf0 then...
        HSPARWED

and fib_Protection == 0x0f then...
        --------

It seems silly to have some bits active high and others active low, but
that is what it turns out to be.


Phil.

-- 
o|      ///   Phil Kernick              EMail:  phil@adam.adelaide.edu.au    |o
 |     ///    Departmental Engineer     Phone:  +618 228 5914                |
o| \\\///     Dept. of Psychology       Fax:    +618 224 0464                |o
 |  \///      University of Adelaide    Mail:   GPO Box 498 Adelaide SA 5001 |