Slashdot Mirror
Rethinking the Nature of Files
An anonymous reader writes "Two recent papers, one from Microsoft Research and one from University of Wisconsin (PDF), are providing a refreshing take on rethinking 'what a file is.' This could have major implications for the next-gen file system design, and will probably cause a stir among Slashdotters, given that it will affect the programmatic interface. The first paper has some hints as to what went wrong with the previous WinFS approach. Quoting the first paper: 'For over 40 years the notion of the file, as devised by pioneers in the field of computing, has proved robust and has remained unchallenged. Yet this concept is not a given, but serves as a boundary object between users and engineers. In the current landscape, this boundary is showing signs of slippage, and we propose the boundary object be reconstituted. New abstractions of file are needed, which reflect what users seek to do with their digital data, and which allow engineers to solve the networking, storage and data management problems that ensue when files move from the PC on to the networked world of today. We suggest that one aspect of this adaptation is to encompass metadata within a file abstraction; another has to do what such a shift would mean for enduring user actions such as "copy" and "delete" applicable to the deriving file types. We finish by arguing that there is an especial need to support the notion of "ownership" that adequately serves both users and engineers as they engage with the world of networked sociality. '"
I've always thought it would be useful if you could mark as file as automatically deleting at a certain date. If you create a temporary file, it would be nice to flag it as "delete after 60 days" so it doesn't need attention in the future. (The same functionality would be really useful for emials...I want to save this email until after the event (or whatever it's about) and then have it automatically deleted.) I once saw the file functionality on a custom Cray operating system in the 1977.
Don't worry, user, of course you own those little files of yours.
We just want to install some robust Technological Protection Measures to preserve your ownership of those files across all devices and platforms and legal systems aligned with international norms... Totally harmless, nothing to worry about.
No, they're talking about DRM. They try to deny it a few sentences later, but how else would you implement a system where any given file downloaded off the web could be deleted by a central authority at any time?
SJW: Someone who has run out of real oppression, and has to fake it.
DOCUMENT=~/myschematics.pdf
SHAID=$(sha512sum "$DOCUMENT" | cut -f1 -d' ')
mkdir heap
mv "$DOCUMENT" "heap/$SHAID"
mkdir tags
mkdir tags/Schematics
mkdir tags/Pentagon
mkdir tags/Operation_Zesty_Lemon
ln "heap/$SHAID" tags/Pentagon/
ln "heap/$SHAID" tags/Schematics/
ln "heap/$SHAID" tags/Operation_Zesty_Lemon/
Life is just nature's way of keeping meat fresh.
The cloud idea likes to project an illusion of it not mattering where the file is, but it is predicated on (more or less) limitless bandwidth with near zero latency, and limitless local storage/cache. If the file you want is not on the local hard disk then it isn't. If your OS needs to fetch it behind the scenes then you need to wait until it arrives. Yes you might think you don't want to know where the file is physically, but when it takes ten minutes to open a file that should take ten seconds, you will probably want to know why (oh, it's in another country and the network is busy because everyone is watching some new TV prog, i see now). Not knowing where the file is just means needing to ask all the time. Is it really better not to know, than just knowing in the first place, and making sure it is where you need it to be? Bandwidth will never be unlimited and latency will never be zero. We are routinely working on 10GB files now where I work, and you always need to know where they are, and to care because however big the pipes are and how ever big the disk space and the RAM, the data streams grow even faster. The technologies underlying data capture devices obey their own version of Moore's law, frequently with higher multiplicities.
Korma: Good