[Coco] Undocumented NitrOS9 system call (Boisy?)

Thu Nov 5 03:15:05 EST 2015

Thanks Aaron, I guess I was just looking for verification on my logic :-)
I hadn't even thought of looking in RBF to see what the call actually did.
And yes, if that call can be used as a setstat as well... then the attributes can be changed by any user... no security. But I doubt very seriously anyone on my 1 user network is gonna try to hack my 30 year old system anyway :-)
As for security, this could be done with ded anyway, or any direct sector read and write to the file descriptor.

Apparently, other versions of OS9 used this method/call as the changelog notes "for compatibility with other systems" and the comments rbf.d say "68k", so I assume this was an OSk or OS9000 call originally.

The main thing I'm trying to accomplish is to get the attribute byte from the file descriptor. From everything I read and see, there is only two ways to know if a filename is a "file" or "directory" and that is either by checking the attribute byte, or attemping to open the filename as either file or directory (which I was doing). I also needed the attribute byte for the "attr" utility I'm working into MShell to be able to set file attributes on the fly.

The whole thing is the last step into finishing the batch copy/move/delete operations for MShell. I needed to know in advance if any given filename in my directory listings were file or directory.

Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
Global Moderator for TRS-80/Tandy Color Computer Forums
http://www.tandycoco.com/forum/

E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: Aaron Wolfe <aawolfe at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Wed, Nov 4, 2015 10:28 pm
Subject: Re: [Coco] Undocumented NitrOS9 system call (Boisy?)

In the rbf module you can see what SS.FDinf does:

SSFDInf cmpb #SS.FDInf
bne
L056B
lbsr L0D72 check for sector flush
bcs Gst5FF
ldb R$Y,u get MSB of sector
#
ldx R$U,u get LSW of sector #
lbsr L0CEB read the sector
bcs Gst5FF error,
return
ldu PD.RGS,y get register stack pointer
ldd R$Y,u get length of data to
move
clra clear MSB
bra L0564 move it to usr

Basically just reading some bytes
from the sector specified into your
process memory, which makes sense given how
the RBF file system works,
basically a directory is just a file with the
filenames and the lsn of the
sector containing that file's descriptor.  Looks
like you have the
arguments correct to me.  Should work fine and much faster
than opening
files.

On Wed, Nov 4, 2015, 9:19 PM Bill Pierce via Coco
<coco at maltedmedia.com>
wrote:

> In messing with my directory read in MShell, I
was looking at the NitrOS9
> "dir" cmd to see if I could use that code to make
my directory reads faster
> by using ML code instead of C. My problem is I want
to read the file
> descriptor info for each dir entry when I read the dir
(similar to "dir
> -e").
> I have a routine that does this, but it's so slow, I
can't use it when the
> dir is read. I use it when the user requsts file stats,
then it reads just
> that file's descriptor, but I really need them read all at
once. To read
> this info in C, inline in my program, it takes about 3 minutes
on a dir of
> 592 files (my cmds dir :-), and this is reading it into a memory
buffer.
> The nitrOS9 dir cmd scrolls the info on the screen in just a few
seconds,
> and with all the print stuff happening as well.
> My program uses the
getstat "SS.FD" call which returns the file descriptor
> data, but to use this
call, the file has to be opened. So my program would
> have to open and close
592 files on my cmds dir to get all the info in one
> shot.
> In looking at the
NitrOS9 dir cmd, it uses "SS.FDInfo", which according to
> the changelog, is a
new getstat that was added by Boisy in Nov of 2005. I'm
> not sure if it was
actually new, or just undocumented and never used until
> then.
> This call does
not seem to require the file to be opened. The directory
> itself is already
open, so it seems to load each file descriptor location
> from the tail end of
the filename in the directory listing (bytes 30-32 of
> the dir entry).
> Now my
question is... what are the calling parameters of this getstat?
> The list in
the dir cmd is:
>
> * Use SS.FDInf to get the file descriptor sector
> pshs  u
>
lda   <dent+DIR.FD
> ldb   #FD.Creat-FD.ATT
> tfr   d,y
> leax  <fdsect,u
> lda 
<dirpath
> ldb   #SS.FDInf
> ldu   <dent+DIR.FD+1
> os9   I$GetStt
>
> dent is
the 32 byte buffer in which the dir entry is stored. DIR.FD is the
> last 3
bytes of this buffer (file descriptor offset). #FD.Creat-FD.ATT is
> equivilent
to 16 (size of the descriptor buffer). So from the above
> listing, I'm assuming
(after all regs are loaded) that:
>
> A=path
> B=SS.FDInfo (getstat cmd)
> Y:
Y/MSB=MSB of file descriptor offset (24 bit) Y/LSB=Number of bytes to
>
retrieve
> X=Address of destination buffer
> U=LSW of file descriptor offset (24
bit)
>
> Does this seem correct to you NitrOS9 asm gurus?
>
>  If this is
correct, I can do the equivilent in C or even asm and not have
> to open and
close every file in a dir as that's what's slowing down my
> current method.
This just seems to do direct reads from the file descriptor
> without opening
the file... correct? (Boisy maybe?)
>
>
> Thanks :-)
>
>
>
> Bill Pierce
>
"Charlie stole the handle, and the train it won't stop going, no way to
> slow
down!" - Ian Anderson - Jethro Tull
>
>
>
> My Music from the Tandy/Radio Shack
Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
>
Co-Contributor, Co-Editor for CocoPedia
>
http://www.cocopedia.com/wiki/index.php/Main_Page
> Global Moderator for
TRS-80/Tandy Color Computer Forums
> http://www.tandycoco.com/forum/
>
> E-Mail:
ooogalapasooo at aol.com
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
>
https://pairlist5.pair.net/mailman/listinfo/coco
>

-- 
Coco mailing
list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco