Imagine a hypothetical implementation which works like this: Consumer asks for a file, we don't find it in Library, nor is the "we're migrating file", we create the "we're migrating file", it's present in Root. We start a copy in the background and return some file handle (probably a proxy). Any writes are written to the "we're migrating file" if that part of the file exists in addition to the original. When the copy completes, we rename "we're migrating" to the correct file. Then we delete the original. Ian wrote: > It might be. > The File API doesn't impose any sort of model for read/write patterns. > Reads and writes can happen anywhere in a file; > we can't enforce that a file is written out entirely in one call, > so there may not be a point where we can say "it's done; delete the old one".
> It's also entirely possible for multiple readers to be open on the file, > and for another thread to have a writer open, > writing somewhere in the middle of the file, > so I would expect race conditions. > This isn't *impossible*; > there have been OS filesystems which do this for a long time, > but it seems to me to be a lot more work than writing a tool for developers > to use for migration, > and much more error prone. Perhaps we should start with that. Shouldn't someone write a tool which scans for consumers and offers a survey and let's the developer pick an answer with which it rewrites the file?
