trb@stag.UUCP ( Todd Burkey ) (10/04/87)
References: In article <9409@brl-adm.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: >If anyone needs a public-domain implementation of getcwd(), >I now have one I can send you. - Gwyn@BRL.MIL Please post it to the sources...I am sure enough people could learn from it. PS. (this is a long PS...) I am thinking of porting a program I developed for the Atari ST over to Unix (initially to my Symmetrics BSD 4.2). The program (HDSCAN) is something like a combination of SWEEP, XTREE, and 1DIR (all IBM PC programs that deal with managing a hard disks file contents.) I designed HDSCAN after using a lot of different Hard disk utilities and environments (both mainframe, mini, and pc's) and basically shot for a simple interface and speed. The program will scan all directories on my ST's 30 meg hard disk (getting file name, size, protections, date, etc) in about 2 or 3 seconds (that is for only 1400 files). After scanning, the user is presented with a scrolling window (for file names) with seperate windows for the size, date, tagged size, etc which is updated as the user scrolls through the files in the window with cursor keys. There are a lot of options for instant viewing or hexdumping or 'strings'ing or arc-viewing of the file currently under the cursor, as well as options for running user-defined programs on the file (assign a key to wc). Plus things like tagging and sorting by name, date, or size...lots of things which I wish I had on the Symmetrics. Now, I know how to do most of the things I need to do to port the application over (I was using MWC on the ST which has quite nice Unix compatibility), so all I need to do is xlate my bit blit and other graphic screen routines into curses and find a fast way to scan the hard disk on my Symmetrics. The big question is...can I scan a file system on unix like I did on the ST? Basically, on the ST, I did raw sector I/O on the FAT table area of the hard disk, recursively working my way through the data pulling in new FAT table sectors when needed. Sounds messy, but I personally don't like using 'standard' file access calls if said calls take 10-50 times as long as a short routine that bypasses them in some way. I realize that this may mean that only sys admins may end up being able to use my program on Unix systems (file security issues will probably require this), but that is ok since I think the sys admins would get the most practical use out of it. Is there anyone out there that can point me in the right direction with high speed 'reading' of the unix file system info (note: I don't want to be able to write using raw i/o...just read, I don't back my stuff up enough to feel like using my hard disks for that kind of experimenting :-). Oh yes, depending on how many days we get snowed in this winter, this project could take to next spring to port...less and less free time these days...and so many toys... -Todd Burkey trb@stag.UUCP "If going to the opera is so fun and intellectually stimulating, why the %^#% do I have more fun staying home and writing a program?"-recent failed attempt.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/06/87)
In article <225@stag.UUCP> trb@stag.UUCP ( Todd Burkey ) writes: >... The big question is...can I scan a file >system on unix like I did on the ST? Basically, on the ST, I did raw >sector I/O on the FAT table area of the hard disk, recursively working >my way through the data pulling in new FAT table sectors when needed. >Sounds messy, but I personally don't like using 'standard' file access >calls if said calls take 10-50 times as long as a short routine that >bypasses them in some way. I realize that this may mean that only sys >admins may end up being able to use my program on Unix systems (file >security issues will probably require this), but that is ok since I >think the sys admins would get the most practical use out of it. Yes, if you can read the raw disk device file, you can interpret the information as you see fit, including duplicating all the UNIX kernel support for the file system structure. However, I don't recommend bypassing the kernel like this, because you would end up with a filesystem-specific utility, and porting it to other UNIX filesystems could be a drag. Indeed, UNIX System V Release 3.0 and later provide the hooks for multiple concurrent file system formats, and there are also systems such as NFS where the only meaningful information is that obtained with the help of the kernel (e.g. getdirentries()). But if you nonetheless wish to proceed with the original idea, your best bet is to obtain the source for "fsdb" or at least "fsck" for your system and use that as a guide to interpreting the filesystem data structures.