[Coco] Nitros9/Scripts question

[Gene Heskett]

On Tuesday 09 December 2014 23:35:33 Willard Goosey did opine
And Gene did reply:
> Os9 supports "hard links" in unix terms... it's just that dcheck
> doesn't know about them and will complain. Since cross-linked files
> are one of RBF's main failure modes it's better to avoid the false
> alarms... :-(
> 
> 
> Willardآ 
> Sent from Samsung tablet

Well, since dcheck already supports keeping scratch files, it should not 
be too hard for it to keep a third file on the -pw media, which contains 
the names and the FD.SEG data, one per line, of any files it finds whose 
link counts are > 1.  Then the allocation map miss-match can look it up, 
keeping it in memory if it finds an apparent duplicate, and skip forward 
by that FD.SEG's sectors. and invalidate the name in the buffer, and keep 
going with its compare until it finds another apparent duplication, go 
search the scratch file, checking for a name match, if, reload the buffer 
and check the FD.SEG's for a matching location, find a match and advance 
the allocation map bit pointer by the FD.SEG size.

In other words, report the error only if that filename is not in the file 
of "link count >1 entries" in the third scratch file.
 
Suggested data format for this 3rd file would a hex byte number for an 
offset to the hex byte containing the size of the FD.SEG section, then the 
name, leaving the set last byte in place then the length of the valid data 
for this entry which would by then be reduced to byte size as the max is 
then less than an INT, then 5 byte FD.SEG's until no more, and an EOL 
byte. I might even skip the EOL byte since any byte in the string could be 
both a valid byte and an EOL. We might have to invent an EOL INT to mark 
the end of this entry, perhaps an $CD878D to make it both very unique and 
still usable. when stripped of the 8th bit, its printable including the 
BEL char so the list would go by on-screen while dinging the speakers once 
per entry.  May as well entertain the by now bored user?

The needed memory buffer to hold that could exceed a sector since the 
offset byte and name could be 32 chars, and the FD has the potential for 
48 FD.SEG's, that is an additional 240 bytes, so this extra buffer would 
need to be defined for $10F bytes. That would be a bit of extra data 
munching involved in generating that file in the first scan, and again 
when it finds an apparent duplicate allocation.

If this dcheck "problem" is whats keeping folks from using these hard 
links, then this stuff s/b added to dcheck so it shuts up.  But since the 
heavy lifting has already been done by then, there may as well be a 
"HARDLINKS found" list in its output, perhaps even switchable to shut that 
off but make the default unswitched state show them just to remind us 
users that they are there. 

[...]

Thinking about the above while waiting for some caffeine & morning pills 
to kick in, all we'd really need in this file, is a set of the 5 byte 
FD.SEG's occupied by any file with a link count > 1. Don't actually need 
the name etc, just search the file once generated, for a matching FD.SEG 
address and advance the counter by that FD.SEG size?  Seems simpler to do.  
That would preclude naming the hardlinks unless a separate, 4th workfile 
is kept that contains the filenames with a >1 link count. I think dcheck 
knows what directory it is working it, so this list could be built showing 
the full paths to the file with a std printable EOL per line.  That file I 
would nuke at the dcheck entry, and leave behind for a work file for the 
user to consult later in case he wants to do some housekeeping.

Sounds like a plan for a bored, cold winter weeks coding. ;-)




Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS