info-vax@ucbvax.ARPA (01/10/85)
From: Gail Rubin <grubin@bbn-spca> I don't know what the diskquota file format is but I have code fragments that use qio's to read quotas. Since the format is not documented but methods of reading and writing it via qio's to the ACP are, I would think you are much better off using qio's. If you want further info, let me know. -- Gail Rubin, grubin@bbn-spca
info-vax@ucbvax.ARPA (07/27/85)
From: <PMANERA%NYBVX1.BITNET@WISCVM.ARPA> 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
info-vax@ucbvax.ARPA (07/28/85)
From: JERRY LEICHTER <leichter@yale-apvax>
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
-------
------info-vax@ucbvax.ARPA (07/30/85)
From: decwrl!dec-rhea!dec-fdcv09!ornstein@BERKELEY (Ian Ornstein PK03/2-28C DTN 223-9145)
------------------- Reply to mail dated 28-JUL-1985 21:55 -------------------
Peter,
If you have $ COPYEed files to other users,
then
they are charged to *YOUR* uic quota
else
I have no idea
end-if.
Ian Ornstein
ps deleting the files with your uic from the other accounts will restore
your quota.
try..
$ DIR/OWNER dev:[000000]info-vax@sri-kl (10/24/85)
From: Rob Rimbold <rimbold%ulowell.csnet@CSNET-RELAY.ARPA> Does anyone know what the file structure of QUOTA.SYS is? I am going to write a program to keep track of disk usage, and note when large increases or decreases in user accounts occur. Any information, or thoughts on this subject would be appreciated. ~Rob
info-vax@sri-kl (10/24/85)
From: Tony Li <Tli@Usc-Eclb>
Date: Wednesday, 23 October 1985 11:50-PDT
From: Rob Rimbold <rimbold%ulowell.csnet at CSNET-RELAY.ARPA>
To: Info-VAX at sri-kl.arpa
Re: Diskquota
Does anyone know what the file structure of QUOTA.SYS is? I am going
to write a program to keep track of disk usage, and note when large
increases or decreases in user accounts occur. Any information, or
thoughts on this subject would be appreciated.
~Rob
You needn't look at QUOTA.SYS. You can talk directly to the ACP and
ask it about the quotas.
Now it's time to QIO,
to all our chock-full disks,
Cheers,
Tony ;-)