Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!info-vax From: info-vax@ucbvax.ARPA Newsgroups: fa.info-vax Subject: Re: Diskquota (Again) Message-ID: <9407@ucbvax.ARPA> Date: Sun, 28-Jul-85 13:33:22 EDT Article-I.D.: ucbvax.9407 Posted: Sun Jul 28 13:33:22 1985 Date-Received: Mon, 29-Jul-85 08:02:21 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 74 From: JERRY LEICHTER Ok, I've spent some time digesting what you all told me last time, and doing just about everything short of pulling out my hair. The original question was "Why the difference between DISKQUOTA and DIR/BY?" I have deleted an entire tree; run ANAL/DIS/REP; rebuilt the quota file. The UIC in question shows 1136 blocks used in DISKQUOTA; DIR/BY: "no files found" (grrrrr)! Any (more) ideas? Peter First of all, you say you ran ANALYZE/DISK/REPAIR, but you don't say what messages, if any, it gave you. There might be something instructive there. (As one possibility, if you ran it with SYSPRV but not BYPASS, it may have been unable to deal with some situations and just ignored them.) There are plenty of ways to "lose" files so that DIRECTORY (and RMS in gene- ral) can't find them easily. For example, it is not hard to build directory "nests" more than 8 levels deep. Starting from the MFD, nothing more than 8 levels down will be visible. Note that such deep nests may be quite legiti- mate, since with V4 you can have rooted directory structures with 8 levels, plus 8 levels below the "root". (For example, ROOT could be DISK:[A.B.C.D.]; Then ROOT:[E.F.G.H.I]FOO.FOO is a legitimate file spec, but DIRECTORY starting from DISK's MFD will not find FOO.FOO.) With rooted directories, you can legitimately make directory structures that are 16 levels deep; but you can also make them as deep as you like, although the resulting files won't be accessible at all. I don't know if ANALYZE/DISK will consider this to be an error. There are more elaborate ways to "hide" files. For example, if a directory is simply renamed so that its type isn't DIR, or its version isn't 1, RMS won't use it. Again, I don't know if ANALYZE/DISK will complain about this. If I wanted to be REALLY elaborate, I could build a loop of legitimate dir- ectories. A file in one of these would appear to not be "lost", but it would not be accessible at all starting from the MFD. Again, ANALYZE/DISK might or might not notice this. Actually, there is no reason to be quite so baroque. What DIRECTORY command did you use? If you used the obvious DIRECTORY [*...], you will not have looked in the MFD, which is never included in any wildcard operation - the answer to your puzzle COULD be as simple as "the file is in [000000]". It could, theoretically, even be a single, huge directory file in [000000]. If, on the other hand, you used DIRECTORY [000000...], you would have checked the MFD - but you would then have added an extra level to every directory spec that RMS formed. As a result, any directories 8 levels below the MFD would now appear to be 9 levels down, and would not be searched. There IS one thing that is guaranteed to find your mysterious files: Do an ANALYZE/DISK/LIST=filespec. This will produce a listing of every file in the disk's index file - exactly the database that DISKQUOTA (and ANALY/DISK/REPAIR for that matter) use. Files cannot be hidden from this operation. Unfortu- nately, you can only get a listing of EVERY file on the disk, then search it yourself. Further, the only information you will get about the file is its name, owner UIC, and file id. You can use the file id to delete the file, though you will have to write a program to do it. With somewhat more effort, you can use the file id, and the appropriate ACP calls, to trace back the directory backlinks in the file header and find out where the file "lives". A more direct way to get this information is to use ANALYZE/DISK/USAGE, which produces a "listing file" designed for program, not human, consumption - and which includes the directory spec. Another thing that MIGHT work: Use BACKUP/FAST/OWNER=[g,m] to try to back up the miscreant files. The /FAST is essential: It tells BACKUP to use the index file directly, rather than trying to work down the directory tree, which we already know won't work. Good luck, and please report back what you find! -- Jerry ------- ------