3 ms·

The author writes "CP/M 2.2 had no mechanism for resizing files", but that is not exactly true. CP/M had a submit-command, which would read a text-file contain

The author writes "CP/M 2.2 had no mechanism for resizing files", but that is not exactly true. CP/M had a submit-command, which would read a text-file containing a list of commands and write out a file named $$$.SUB to the A:. Later when the CP/M booted (via a cold start, or a warm start which was triggered by pressing Ctrl-C) it would be processed. The $$$.SUB file was processed in reverse, and it would be assumed to contain N entries of 128 bytes each. The last record would be read, the command be executed, and the file would be resized down by 128 bytes. So given input like: FOO BAR BAZ The CP/M command-processor (i.e. shell) would run "BAZ", truncate the $$$.SUB file by 128 bytes. Then it would do the same, executing "BAR", truncating down, and then running "FOO", truncating down to zero, and erasing. How do I know this? I wrote a CP/M emulator and had a devil of a time working out the behaviour, but the CP/M "Close File" call will truncate a file is some values of the FCB tell it to. Since CP/M itself used this I can only assume that user-programs did too.

rep_lodsb 2y ago
"Close file" will update the directory entry for the current extent. It doesn't (AFAIK) delete other extents or free any blocks that have been allocated to the file. The "last record" field of the FCB / direntry will be decremented for each line, so that the shell can keep track of where in the file it should continue (this can't be stored in memory, because programs are explicitly allowed to overwrite the command processor). But the space on disk won't be freed until it's done executing all commands in the file. For an emulator it makes sense to actually truncate the file, because on other systems there is likely no way to store a "logical" file size that is shorter than the actual one.

rep_lodsb 2y ago

"Close file" will update the directory entry for the current extent. It doesn't (AFAIK) delete other extents or free any blocks that have been allocated to the file. The "last record" field of the FCB / direntry will be decremented for each line, so that the shell can keep track of where in the file it should continue (this can't be stored in memory, because programs are explicitly allowed to overwrite the command processor). But the space on disk won't be freed until it's done executing all commands in the file. For an emulator it makes sense to actually truncate the file, because on other systems there is likely no way to store a "logical" file size that is shorter than the actual one.