[e-lang] File API taming

[Kevin Reid]

On Mar 19, 2009, at 21:07, ihab.awad at gmail.com wrote:

>
> The asymmetry, however, is that *asking* a file to change its own
> media type is no longer the same: In one case, the file itself has
> that authority; and in the other case, the file has to consult its
> directory saying, "please rename me from 'foo.txt' to 'foo.doc'".
>
> That said, the directory 'd' could, if desired, initialize 'f' with a
> function that closes over  'd' and does the renaming, without giving
> 'f' direct access to 'd'.
>
> Does that sound reasonable?

Yes, entirely reasonable, but IMO unnecessary. Once you're mapping  
caps onto a traditional filesystem, you might as well just write the  
file object to be able to rename itself in its directory, primitively.

Note that, however implemented, this operation can lead to name  
conflicts, e.g. if both foo.txt and foo.doc exist, and your choices are:

   1. have the operation fail when foo.doc exists ("leaks" one bit to  
the client)

   2. overwrite foo.doc (potentially dangerous: foo.txt becomes  
authority to write foo.*)

   3. have the directory refuse to grant file caps to foo.txt if  
foo.doc exists (limiting)

If you are actually writing a capability filesystem, then -- don't use  
filename extensions; it's a lot simpler. Except I don't know what a  
perfect solution is if you're gluing legacy apps, which expect  
extensions, to a capability FS with type metadata. Perhaps it would  
work well enough to let filename extensions just be part of the  
filename, and have the type field also exist separately -- no  
connection between them.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>