And of course there are temp file usage. Like when disk space was very small and files were usually stored on tape unless they were constantly used.
The tape file was read as need by the editor program, which only loaded the parts being worked on with some extra to reduce the wait time for new data to be read. The changes were written to temp files on the disk, and a final write was back to the tape in one of two main ways. 1) Only the tape blocks changed were written, null data padding allowed minimization of the “shift up/down effect” and the directory blocks of the tape was changed to show the new structure of the file on the tape. 2) The whole file starting from the 1st change was written to the tape.and directory updated to reflect this.
History has given us a number of ways to resolve this issue. I think that encrypted temp files on local disk maybe an option. The client parameters could contain the temp directory options 1) store on disk, 2) use immutable data (wasteful on PUTs), 3) use SD data blocks, 4) memory, 5) some other scheme.
Text files are usually only going to be small and a few MB is large, DOC, OSF files are larger but usually a few MB is considered large. Looking at my text and DOC/OSF files it is unusual to find one more than 1MB.
The issue of user edited files being more than 3 MB at this time is not the usual file. Image and other more voluminous file formats may cause more issues and changes to them are also more likely to involve most of the file.
It is unlikely that any special processing other than using temp files would be needed for text, doc, osf files since they will be rarely more than 3 chunks.
It maybe a lost cause to try and introduce special processing for image and other voluminous file types since changes to them involve large percentage of the file.
Temp files will be the key to editing and most editors already use them. The focus maybe better spent on special processing to allow the client to have the temp directory/files stored according to the users wishes and level of security (of data contents and data loss).