rh2y+@andrew.cmu.edu (Russell E. Hoffman, II) (12/18/90)
Thanks to those of you who replied. It turns out that (after doing an
#include <errno.h>) the error returned by _gs_gfd was 000:201 - Invalid
path number. Further investigation revealed that this was caused by the fact
that when you attempt to open a directory using open (file,00), it returns
a -1 as the path, indicating an error of sorts. Now here's my real question,
after having resolved this.
There's GOT to be a faster way to get the file descriptors for every file
in a given directory than simply opening each file individually then doing
a _gs_gfd() on the individual files. I have thought about reading all the
directory entries, storing the addresses of each of their FDs in an array
and then opening the physical device (/h0@ or whatever) and grabbing the
FDs all at once, thereny saving a LOT of seek time on the disk, but
the problem is, as Mr. Larson pointed out, you can only run such a program
if you are the superuser, which kind of defeats the whole purpose. There
simply has to be yet some other way, because when I do a 'dir -e', it
takes about one-fifth the amount of time it takes my program to accomplish
the same thing. Any hints/suggestions?
Thanks in advance,
Russell Hoffman
rh2y+@andrew.cmu.edu
Carnegie Mellon Univ.blarson@blars (12/18/90)
In article <EbPMMOa00aw4M670MX@andrew.cmu.edu> rh2y+@andrew.cmu.edu (Russell E. Hoffman, II) writes: > There's GOT to be a faster way to get the file descriptors for every file >in a given directory than simply opening each file individually then doing >a _gs_gfd() on the individual files. I have thought about reading all the >directory entries, storing the addresses of each of their FDs in an array >and then opening the physical device (/h0@ or whatever) and grabbing the >FDs all at once, thereny saving a LOT of seek time on the disk, but >the problem is, as Mr. Larson pointed out, you can only run such a program >if you are the superuser, which kind of defeats the whole purpose. Like I pointed out in my other article, you can have your program setuid superuser. Note that dir is one of the microwares programs owned by 0.0 rather than 1.0, probably for this very reason. The 2.3 update covered how to write setuid programs, it isn't in my copy of the technical manual, and is not the same as on unix. Programs owned by 0.0 can call setuid(0), then setuid(anything). -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.
ralf@ppcnet.ppc.sub.org (Ralf Sauther) (12/19/90)
rh2y+@andrew.cmu.edu (Russell E. Hoffman, II) writes: > There's GOT to be a faster way to get the file descriptors for every file >in a given directory than simply opening each file individually then doing >a _gs_gfd() on the individual files. I have thought about reading all the Certainly there is a way :-) I know about a program named 'dir1' (which is avaliable as source), that is very fast in accessing the file-descriptors (it does a few #asm statements for this). Maybe there's a way to release it to the net (it's PD). Gruss Ralf -- Ralf Sauther | ...doitcr!smurf!ppcnet!ralf | ralf@ppcnet.ppc.sub.org | +49 7274 76825 (voice only) |
davely@mcrware.UUCP (Dave Lyons) (12/21/90)
In article <EbPMMOa00aw4M670MX@andrew.cmu.edu> rh2y+@andrew.cmu.edu (Russell E. Hoffman, II) writes: +Thanks to those of you who replied. It turns out that (after doing an +#include <errno.h>) the error returned by _gs_gfd was 000:201 - Invalid +path number. Further investigation revealed that this was caused by the fact +that when you attempt to open a directory using open (file,00), it returns +a -1 as the path, indicating an error of sorts. Now here's my real question, +after having resolved this. + There's GOT to be a faster way to get the file descriptors for every file +in a given directory than simply opening each file individually then doing +a _gs_gfd() on the individual files. I have thought about reading all the +directory entries, storing the addresses of each of their FDs in an array +and then opening the physical device (/h0@ or whatever) and grabbing the +FDs all at once, thereny saving a LOT of seek time on the disk, but +the problem is, as Mr. Larson pointed out, you can only run such a program +if you are the superuser, which kind of defeats the whole purpose. There +simply has to be yet some other way, because when I do a 'dir -e', it +takes about one-fifth the amount of time it takes my program to accomplish +the same thing. Any hints/suggestions? Dir uses a getstat called SS_FdInf that lets you tell it the block number of the FD you want. This probably won't be a lot faster than opening the raw device, but it's a little cleaner. And if the file is open, RBF gets the FD from memory instead of from the disk. You do have to be super user to make this call but as someone else pointed out, if your program module was created by the super user, it can change it's user id to super user even if it was forked by a non-super user. I don't think there is a C binding function for this call though, so you would have to write that. +Thanks in advance, + +Russell Hoffman +rh2y+@andrew.cmu.edu +Carnegie Mellon Univ. Hope this helps, davely -- |Dave Lyons - uunet!mcrware!davely | Just like a V8 under the hood | |-------------------------------------| of a car made of nails and wood | | The opinions of the party of the | Your big heart's gonna break | | first part shall not be taken as... | your little body |
rh2y+@andrew.cmu.edu (Russell E. Hoffman, II) (12/21/90)
Bob Larson writes: > [paraphrase] you have your program owned by 0.0 and then do a setuid() > and the n you can setuid to any user. I'll have to try that. I thought the program had to be executed by the super- user, not just simply owned by the superuser. _ONE_ of these days I'm going to get around to buying Dibble's book.... I'll try that out and reply on the success/failure. Thanks, Mr. Larson! Cheers, Russell Hoffman rh2y+@andrew.cmu.edu Carnegie Mellon University
zeller@bernina.ethz.ch (Lukas Zeller) (12/21/90)
In article <5AlNrD@ppcnet.ppc.sub.org> ralf@ppcnet.ppc.sub.org (Ralf Sauther) writes: >rh2y+@andrew.cmu.edu (Russell E. Hoffman, II) writes: > >> There's GOT to be a faster way to get the file descriptors for every file >>in a given directory than simply opening each file individually then doing >>a _gs_gfd() on the individual files. I have thought about reading all the >Certainly there is a way :-) I know about a program named 'dir1' (which is >avaliable as source), that is very fast in accessing the file-descriptors >(it does a few #asm statements for this). Maybe there's a way to release it >to the net (it's PD). The trick is simple and effective, but not very nice: There is a GetStat call named SS_FDInf that can be used to access the file descriptor by specifying its logical block number. This eliminates the need to open all the files to apply _gs_gfd() and is therefore much faster. There is, however, a slight drawback to this: Because SS_FDInf gives access not only to file descriptors, but in fact to ANY block of a disk, it would be a severe security hole - if it was available to any user. You guessed it: only the superuser can do it. So the "dir1" mentioned above needs to change its process UID to superuser, which is only possible if the program BELONGS (file and module) to the superuser. ========================== +---------------------------+ ***************** Lukas Zeller |\ E-Mail: /| * Never trust a * ETH Zurich, Switzerland | \_______________________/ | * computer * (SFIT, Swiss Federal | / zeller@ethz.UUCP \ | * bigger than * Institute of Technology) | / ..chx400!ethz!zeller \ | * you can lift * ========================== +---------------------------+ ***************** -- ========================== +---------------------------+ ***************** Lukas Zeller |\ E-Mail: /| * Never trust a * ETH Zurich, Switzerland | \_______________________/ | * computer * (SFIT, Swiss Federal | / zeller@ethz.UUCP \ | * bigger than *
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/21/90)
rh2y+@andrew.cmu.edu (Russell E. Hoffman, II) writes: > There's GOT to be a faster way to get the file descriptors for every file >in a given directory than simply opening each file individually then doing >a _gs_gfd() on the individual files. On the coco, people use SS_FDInf... I just looked in my latest OSK manual and it's in there, also. It basically allows you to read any sector on disk, when you come down to it. Pretty much designed for dir programs such as yours. You open the dir, read in the names and FD lsn's, and use FDInf to grab the first needed bytes from each file's FD. Check the manual tho; I seem to recall it saying something about having to be group superuser or something. best - kev | Kevin Darling | Internet: kdarling@catt.ncsu.edu | OS-9 & | 919-872-7986 anytime | CIS: 76703,4227 Delphi:OS9ugpres | 680x(x)