Unix shell design [was Re: Yes, Unix can do batch renames - Re: Unix handles file extensions "very poorly"?]

Not per se, but upon looking into it, something like that is one of the possibilities I've been turning over in my thoughts. I'd prefer something more radical, though. That's less "encrypted storage" and more "encrypted storage in a way friendly to the Unix storage model". This thing did not fix the Unix model at all well. To pick the thing that gave me the most trouble, you couldn't modify a file after creation; you had to create a new file, which might (or might not) be almost identical to the former version. Storage was separated fairly hard from use; it was designed for distributed storage, and the entity that stores the file need not have the crypto key(s) necessary to decrypt its contents. There was also no delete operation; they recognized, correctly, that there is no way to force another node to delete anything, so they didn't even try - to "delete" something you throw away the crypto keys necessary to decrypt its contents. (I forget whether there was an advisory "I don't care any longer about this content you have" operation.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B