using the -o option causes find to fail oddly.
Closed this issue · 4 comments
The -o option make find log entries to a disk log file. To do this we have to switch from the current drive of
interest to the drive that has the log file, where we write a record, and then switch back.
That action of switching from drive to drive blows the CP/M file search out of the water. It looks like its find
the correct number of things but the things are nonsense.
A possible work around it to buffer all the file names in memory, and waiting until done to print. This unearths a
new problem, you can't know how many drives are present until you try to read each one. At some point you
run off the end of the list, and get the system error message. No way to recover from that. Another issue is that
the amount of ram (64k) really limits the number of file names that can be buffered in ram. With 32k of empty
ram I can get about 2700 file names stashed.
Login vector is not satisfactory, since it only shows which drives have been logged on, not all the drives in the
system.
To fix this we will have to solve the problem of getting a definitive list of drives that CP/M knows about. It keeps
a list of drives, and we can get at it via skullduggery. As for network mounted drives, there also a way to find
them.
part of this problem is now fixed. I can reliably detect if a drive letter is assigned. If there a are gaps it should
now skip over them. This problem is a non issue on cp/m 3 since we just ignore the drive select error. As for
network drives, I need to find a way to detect that cpnet is loaded on cp/m 2.2, again on cp/m 3 this is a non
issue.
I now can figure out what drives are up on the cp/m system and also detect network drives.
Fixed this one, it needed 4 other added features. Find all the known drives, find all the network drives, don't
list to a file while reading directory entries, and don't allocate a log file then delay writing until all the scans
are done, this one writes trash all over the place.