All I can guess is you are thinking of volume names...
I'm thinking of mount points.
In XP pro at least, control panel -> administrative tools -> computer management -> disk management. Find the partition you want to mount somewhere; right click -> change drive letters and paths -> add -> mount in the following empty NTFS folder. This doesn't seem to work nearly as well for CD-ROMs and such as it does for hard drives, but it still works. I just tried mounting my burner as C:\cdrom and it worked.
In other words, you could set up your Windows box to have the same directory structure as your Unix one, with the exception that instead of saying "/foo/bar" you would say "c:\foo\bar", but "bar" can be on a different file system than what's mounted at "c:\".
And unlike many other obscure NTFS features, this one actually has decent UI support.
Repeating the same word in Latin in the old days was very common and considered a good emphasis technique.
Oh, and it still is. That's one of the more common and easier-to-find "rhetorical techniques" that you learn about in English classes and such. See MLK's I Have a Dream speech.
But in this case, I don't think it's a deliberate attempt to do that; what's being emphasized? It just feels like a sloppily-worded sentence.
You're correct more or less. There will probably be downloadable sources and such that also use the same thing, but "any video and audio" is typical Slashdot anti-MS bull.
To be honest, the original site wasn't all *that* informative either. Also, theoretically the non-Windows depts of MS shouldn't really be using that API either. It was one of the things that came up in the US antitrust trial, and apparently the Windows team was not happy that the Office team was using the Native APIs. Leaving them undocumented gives them a lot more leeway if they want to change the interface later, because theoretically only a couple utilities (like autochk) and the various subsystems should be calling them.
If symbolic links were available plenty of cross-platform software would stop supporting drive letters, and people would be told to make a "home" directory with pointers to their personal parts of the "My Documents", etc.
Since drive letters (other than C:) are already unneeded, why would symlinks change things?
If you can't afford the registration fee (which should be kept to a token fee of $5 or so for the purpose of showing that you care, not for the government's profit) then flip burgers between slitting your wrists and writing poetry about how empty you are.
$5 for what? If I'm a photographer on a photo shoot and take 500 pictures (no clue if this is an accurate number, but I do know that they take *a lot*, especially now with digital), is that $5 for the whole bunch, or do I have to pay $2500 (or pick out my favorite 10, pay $50, and destroy the others)?
The closest thing currently at the MS version of sysinternals seems to be "Inside Native Applications". (In all fairness, this second link seems to contain information I don't ever remember seeing at the old SysInternals. But I am very disappointed that the aforementioned link disappeared.)
I think both my undergrad and grad universities are like that too. In undergrad OS we did a user-level threads package, a user-level memory allocator (actually like four of them), and a user-level simulation of a file system. I looked at the syllabus for a past semester of the undergrad OS course at my current home, and they had very similar projects. (In fact, written in Java. At least ours were C/C++.) And my current university's grad dept. is pretty consistently in the top ten of rankings, so it's not exactly a slouch university either.
In other words, don't think that your experience was uncommon or in any real way due to the supposed MS culture.
By "Can I move a stream from one file to another?" I mean "move filename.ext:mystream otherfile.ext:newlocation". I don't mean copying the data. One file gains a stream that is lost from some other file.
I can't vouch for how Windows does it (I'd test if I was booted to it now...), but in my "let's think about what would make an ideal file system", sure.;-)
The read() system call is not normally implemented for directories. It once was how directory reads were done, back when UNIX only had one type of filesystem. It was then kept around for a while, rather useless, but working. Linux even had it long ago, despite not sharing code with the old UNIX systems and not really having any use for the ability.
Even if you use read() on a directory as the implementation, lots of tools still break. The file type can only be one or the other, not both. Either it looks like a file or it looks like a directory. Either way, apps will refuse to deal with it.
Ah, that's true. Oh well.
I'm in an OS class now, and we'll have a project for the semester... maybe I'll think about this and see if there's a good way to implement this for that. Probably would have to change the application-visible interface, maybe to include another bit in the attributes or something like that.
Finally, I want to point you out to something: you have frigging SATA drives! None of my computers have SATA drives because SATA has only been released in 2003! It hasn't become mainstream since 2005. This means you had a brand new high-end computer in mid-2005. WTF? All my computers predate that.
No, it means I have a PCI controller card to run said SATA drives. My box, minus that, the drives it runs, its TV tuner card, and 2/3 of it's 1.5 gig of RAM, is from 2002. It's feeling noticably sluggish.
(On the RAM... I got a stick of a gig of RAM about 17 months ago for only slightly more than it would cost now. Reading newegg reviews it seems that RAM prices went through the roof some time after that point. What happened?)
You, sir, should seriously reconsider your financial priorities and not bitch about a 100$ you miss to make backups of critical data. This data is your future, you do realize that, don't you?
See my previous post. What data is my future? The few photos I'd lose? The hundred hours of Star Trek episodes? Sure, both of those would suck (the former more than the latter, but the latter would still suck), but it wouldn't change my life or my future in any noticable way. The data that could actually have an effect *is* backed up, just not by me, by virtue of being on my school's computers. The other data that's "mine" that I really doubt will have an effect but is irreplacable anyway I have burned to a couple CDs. (That's each file is located on at least two CDs, and most of them more; my semesterly backups tend to be full, so older stuff is on a couple copies, and I burn two copies of each CD.)
Most of my work goes on at school. Most of the work that I do from home is ssh'd into school. Most of the remainder is on files that I email to myself or upload to the school computers.
BTW, while searching info about ADS, it seems the main goal behind its implementation was to be compatible with HFS+
Compatible with HFS's data and resource forks maybe.
But to be compatible with HFS+ would be quite an accomplishment; according to its Wikipedia page, HFS+ was released in 1998. According to this page (admittedly unclearly), a comment above, and this MS document ADSs have been supported in NTFS since 1993.
Whola. I've been a grad student too. Lay low on the partying for a while and you'll have that 100 bucks in no time.
I don't party, and it's not so much as not having 100 bucks as having better things to save it for. After cost-of-living expenses, I have probably 3-400 dollars a month. (This month I have segregated fees to pay to the university so that eats up $300-some, and it's cold and heat might drop that below $300/mth for the next couple months apart from that). But at the same time, I also don't have a car, and at the moment I deem that more important than getting a hard drive to use just for backup. And with that little money, I'll want to not have any car payments to make; insurance is going to be enough.
And there are other things too (like a new computer) that would take priority over backups too....then install subversion (or CVS, if you prefer that)
I've only used CVS a tiny bit, but it sucks. I'm a Subversion guy.:-p (I just say CVS in the original post because it's sort of the quintissential VCS. And it's short.)
Sure, it won't store your vacation pictures as a backup, but the *really* important things like your thesis can easily be backed up. Heck, that should even be backupable on a DVD, because mine fitted on a 1.44MByte floppy;-)
There's part of the reason that I don't have a regimented backup scheme... a good part of the data that's not easily replacable (at least with a few days to reinstall stuff) is on network drives at school. And believe you me when I say that those *are* backed up... we even have ready access to the previous day's backup at any time in case we delete something important, and apparently can persuade them to go back further if we explicitly request it. So really I would lose three things by not backing up. One is the time it takes to reinstall, two are irreplacable or hard-to-replace stuff that are probably weakly infringing someone's copyrights (like an entire hard drive devoted to Star Trek TNG episodes I recorded off of TV back when I was in the dorms and still had cable; that drive was supposed to mirror another in a RAID array, but apparently the SATA card's manual I have is lying about being able to build an array from an existing disk so I never set that up so had an extra drive), and a good portion of my photos. I should probably back up those photos one of these days... I have a 40 gig in an external USB enclosure that's plugged in RIGHT NOW that I have or could make space on...
The rest I have either on my semesterly backup CDs for really old stuff or school drives.
(You can tell I didn't learn my lesson from when I did have a drive failure... though I got off lucky then because only one partition -- the one I cared about the least, in fact almost not at all -- was unrecoverable. Though that incident did spur me to buy the second drive for the RAID 1 array that never got set up and now has about 85% of TNG.)
You have a number of good questions; here are my thoughts.
Normal APIs don't support extra streams. Getting fopen() to work with streams is a hack, to put it mildly.
This is still *definitely* in the realm of tool support in the way I'm thinking of it. In some sense it's at a higher level, because it makes pepole who are trying to make tools in the first place jump through hoops, which is why it's not *really* in tool support as such. But what I mean by 'tool support' is just... MS introduced these streams but almost no support for using them either as an end user or as a programmer. And I don't know why. It's like there was a disconnect between the peoeple designing NTFS and the people actually implementing, well, everything else. Who knows, perhaps probably there was. More about this in a second.
The notation used on Windows is... interesting. If you are in D:\ with a file called C, does C:foo refer to a stream on D:\C or to a file called foo in the current directory of the C drive?
On a Linux or MacOS system, all characters except '/' and '\0' are valid in filenames, so we have nothing to spare. No, you can't steal the ':'.
These both go together, because they're more or less the same thing. There are two issues here, which is how how streams are treated by APIs, and how the end user sees them. Totally technically, the second point really isn't EVER dictated by the filesystem or OS even now; it's really up to the application, shell, whatever how they show the end user. There are conventions that essentially everyone follows though, and establishing a reasonable convention for how they should be treated I think would be part of the design of this filesystem.
But this leads to the API issue. What should the interface be? I think that an API that takes 'filename:stream' (no matter what the special character is) to open that stream is a badly-designed API. Instead of fopen("foo.txt:bar"), I think it would be better to do something like fopen("foo.txt", "bar"). I don't think there's any more reason for keeping the filename and stream together than any other pair of arguments. This would require changing the system call API though... On Windows, not actually that big of a problem probably since the system call API is independent of the programmer-visible APIs and adding new Windows API functions is clearly not an issue for them, but I guess on Unix there's considerable intertia here. The point of all this is that the only place that special characters would be necessary is from the user's perspective.
And from the user's perspective, there's already often places where we need to do weird things to make file names work. For instance, file names can contain spaces. But 'cat some long file name.txt' isn't going to work, so you have to quote the file name or escape the spaces. In other words, spaces are a special character because they delimit command line arguments in your typical shell. The ability to escape spaces with backslash means that backslash has become a special character. At the very least, a shell that does this needs to distinguish between 'cat file1\ file2' meaning 'cat "file1 file2"' and 'cat "file1\" "file2"'. (Yeah, not legal syntax because the \ escapes the ". Pretend it didn't.) Quotes become special in a similar way. So I don't think there's a big elegance problem with introducing : as a stream separator and requiring it to be escaped if it's part of a filename. I don't exactly remember encountering many file names with ':' in them even though it's allowed, so I think this impact would be minimal to nil. (Though existing stripts and stuff might break; this is a problem.)
Today I can copy a file with the dd command. I can copy a file using the cat command and shell redirection. Multi-forked files would lose data.
This is a good point, though... maybe unimportant? Maybe that's how you want the behavior to go. I don't know.
It looks like you need a directory... why not use one? This is how MacOS X apps w
[storing diffs] doesn't work so well with binary files
This is, of course, true. (OTOH, one reason that I think that 50% overhead for the 100 revisions is VERY VERY overblown is that I have a few binary files in our current repository that aren't part of that 6 MB checkin.)
I'm not sure exactly what a versioning filesystem should do with binary files, but I do think there would have to be something that treated them differently, and I have a few ideas. At the crudest implementation, you could just drop binary files completely, and only version text files. Or do the same thing, but instead of deciding whether to store a new version based on the binaryness of the file, do it based on whether the ratio of the diff is larger than x% of the size of the file itself. You could also just treat them the same during creation, but then favor deleting binary revisions either directly or indirectly when you're looking for space. (When you're garbage collecting essentially, only with a definition of "garbage" that lets you delete old revisions. I also suspect this would be necessary in such a file system.)
One slick idea I thought of would be to allow 3rd party apps to register what you might call a 'diff engine'. In the same way it can say 'open.doc files with msword.exe' (or oowriter.exe, or whatever), it could say 'diff.doc files with msworddiff.exe'. The output of msworddiff would then be stored as the diff, and msworddiff would be used to generate old versions*. (Which leads to a big drawback of this approach, which is that you must have the diff engine around when you do that. Maybe MS trying to set a standard -- or even requiring through some signing thing, as many drawbacks as come with that approach -- of releasing these for free, and making them (MS's and 3rd partys') available in an online directory would alleviate this somewhat.) This would allow it to pick up structure from binary data at least a lot of the time.
*Note: I don't know if DOC would benefit as much from this; like I don't know if it would be considered binary or text. But even if it's text data and can be efficienly diffed, the idea still stands I think.
I don't claim to know all of the tradeoffs of how to do this, or how to present versions to the user, or what degree of control to give regarding a lot of these aspects. Maybe there's a Ph.D. thesis here for someone in human factors.:-p (Actually that's somewhat tempting me now that I think about it... but I don't have the psych background I probably should.) But I do think that CVS+$(FAVORITE_FILE_SYSTEM) would be pretty sweet, and might even make a noticable change to the way people think and/or treat about files.
Slashdot Mirror
All I can guess is you are thinking of volume names...
I'm thinking of mount points.
In XP pro at least, control panel -> administrative tools -> computer management -> disk management. Find the partition you want to mount somewhere; right click -> change drive letters and paths -> add -> mount in the following empty NTFS folder. This doesn't seem to work nearly as well for CD-ROMs and such as it does for hard drives, but it still works. I just tried mounting my burner as C:\cdrom and it worked.
In other words, you could set up your Windows box to have the same directory structure as your Unix one, with the exception that instead of saying "/foo/bar" you would say "c:\foo\bar", but "bar" can be on a different file system than what's mounted at "c:\".
And unlike many other obscure NTFS features, this one actually has decent UI support.
Repeating the same word in Latin in the old days was very common and considered a good emphasis technique.
Oh, and it still is. That's one of the more common and easier-to-find "rhetorical techniques" that you learn about in English classes and such. See MLK's I Have a Dream speech.
But in this case, I don't think it's a deliberate attempt to do that; what's being emphasized? It just feels like a sloppily-worded sentence.
Could not be more redundant.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.
(Also, that "sentence" I quoted is a fragment. And you didn't capitalize "i" in the previous sentence, which is actually a run-on.)
You're correct more or less. There will probably be downloadable sources and such that also use the same thing, but "any video and audio" is typical Slashdot anti-MS bull.
Well, it just goes to show, that PMP'ing an operating system ain't easy.
Or 'It's hard out here for a PMP'
To be honest, the original site wasn't all *that* informative either. Also, theoretically the non-Windows depts of MS shouldn't really be using that API either. It was one of the things that came up in the US antitrust trial, and apparently the Windows team was not happy that the Office team was using the Native APIs. Leaving them undocumented gives them a lot more leeway if they want to change the interface later, because theoretically only a couple utilities (like autochk) and the various subsystems should be calling them.
The Windows UI provides easy creation of shortcuts though, which have the same breaking problem.
If symbolic links were available plenty of cross-platform software would stop supporting drive letters, and people would be told to make a "home" directory with pointers to their personal parts of the "My Documents", etc.
Since drive letters (other than C:) are already unneeded, why would symlinks change things?
Um, what?
I can read the article fine, and I'm using FF on Linux.
If you can't afford the registration fee (which should be kept to a token fee of $5 or so for the purpose of showing that you care, not for the government's profit) then flip burgers between slitting your wrists and writing poetry about how empty you are.
$5 for what? If I'm a photographer on a photo shoot and take 500 pictures (no clue if this is an accurate number, but I do know that they take *a lot*, especially now with digital), is that $5 for the whole bunch, or do I have to pay $2500 (or pick out my favorite 10, pay $50, and destroy the others)?
I think he's talking about "Inside the Native API".
The closest thing currently at the MS version of sysinternals seems to be "Inside Native Applications". (In all fairness, this second link seems to contain information I don't ever remember seeing at the old SysInternals. But I am very disappointed that the aforementioned link disappeared.)
I think both my undergrad and grad universities are like that too. In undergrad OS we did a user-level threads package, a user-level memory allocator (actually like four of them), and a user-level simulation of a file system. I looked at the syllabus for a past semester of the undergrad OS course at my current home, and they had very similar projects. (In fact, written in Java. At least ours were C/C++.) And my current university's grad dept. is pretty consistently in the top ten of rankings, so it's not exactly a slouch university either.
In other words, don't think that your experience was uncommon or in any real way due to the supposed MS culture.
At least that comes with some paper! And stock certificates are often even quite fancy-looking.
What are you, my keyboard? That's exactly what I was going to write
;-)
Your keyboard knows what you are going to write? Dude, where do I get me one of those keyboards?
Let you work with GUI programs to get their ease of use and aesthetics and retain some of the power of a shell?
By "Can I move a stream from one file to another?" I mean "move filename.ext:mystream otherfile.ext:newlocation". I don't mean copying the data. One file gains a stream that is lost from some other file.
;-)
I can't vouch for how Windows does it (I'd test if I was booted to it now...), but in my "let's think about what would make an ideal file system", sure.
The read() system call is not normally implemented for directories. It once was how directory reads were done, back when UNIX only had one type of filesystem. It was then kept around for a while, rather useless, but working. Linux even had it long ago, despite not sharing code with the old UNIX systems and not really having any use for the ability.
Even if you use read() on a directory as the implementation, lots of tools still break. The file type can only be one or the other, not both. Either it looks like a file or it looks like a directory. Either way, apps will refuse to deal with it.
Ah, that's true. Oh well.
I'm in an OS class now, and we'll have a project for the semester... maybe I'll think about this and see if there's a good way to implement this for that. Probably would have to change the application-visible interface, maybe to include another bit in the attributes or something like that.
Any function that can pass colons in the filename to the kernel can open alternate file streams, no hacks required
It's still somewhat ugly, and it doesn't work *at all* on many other file systems where : is a legal character in a file name.
This is a largely legitimate reason for not implementing it on, say, ext.
If no other commonly-used filesystem supports a feature...
Read other posts in this thread... HFS+ has it too.
Finally, I want to point you out to something: you have frigging SATA drives! None of my computers have SATA drives because SATA has only been released in 2003! It hasn't become mainstream since 2005. This means you had a brand new high-end computer in mid-2005. WTF? All my computers predate that.
No, it means I have a PCI controller card to run said SATA drives. My box, minus that, the drives it runs, its TV tuner card, and 2/3 of it's 1.5 gig of RAM, is from 2002. It's feeling noticably sluggish.
(On the RAM... I got a stick of a gig of RAM about 17 months ago for only slightly more than it would cost now. Reading newegg reviews it seems that RAM prices went through the roof some time after that point. What happened?)
You, sir, should seriously reconsider your financial priorities and not bitch about a 100$ you miss to make backups of critical data. This data is your future, you do realize that, don't you?
See my previous post. What data is my future? The few photos I'd lose? The hundred hours of Star Trek episodes? Sure, both of those would suck (the former more than the latter, but the latter would still suck), but it wouldn't change my life or my future in any noticable way. The data that could actually have an effect *is* backed up, just not by me, by virtue of being on my school's computers. The other data that's "mine" that I really doubt will have an effect but is irreplacable anyway I have burned to a couple CDs. (That's each file is located on at least two CDs, and most of them more; my semesterly backups tend to be full, so older stuff is on a couple copies, and I burn two copies of each CD.)
Most of my work goes on at school. Most of the work that I do from home is ssh'd into school. Most of the remainder is on files that I email to myself or upload to the school computers.
Can I run VMS on my desktop? Is there ANY non-experimental filesystem that runs on a standard desktop OS that has this feature?
I didn't say "wow, great innovation MS"; I said "this is a great feature to have and I've wanted it for a longtime"
BTW, while searching info about ADS, it seems the main goal behind its implementation was to be compatible with HFS+
Compatible with HFS's data and resource forks maybe.
But to be compatible with HFS+ would be quite an accomplishment; according to its Wikipedia page, HFS+ was released in 1998. According to this page (admittedly unclearly), a comment above, and this MS document ADSs have been supported in NTFS since 1993.
Whola. I've been a grad student too. Lay low on the partying for a while and you'll have that 100 bucks in no time.
...then install subversion (or CVS, if you prefer that)
:-p (I just say CVS in the original post because it's sort of the quintissential VCS. And it's short.)
;-)
I don't party, and it's not so much as not having 100 bucks as having better things to save it for. After cost-of-living expenses, I have probably 3-400 dollars a month. (This month I have segregated fees to pay to the university so that eats up $300-some, and it's cold and heat might drop that below $300/mth for the next couple months apart from that). But at the same time, I also don't have a car, and at the moment I deem that more important than getting a hard drive to use just for backup. And with that little money, I'll want to not have any car payments to make; insurance is going to be enough.
And there are other things too (like a new computer) that would take priority over backups too.
I've only used CVS a tiny bit, but it sucks. I'm a Subversion guy.
Sure, it won't store your vacation pictures as a backup, but the *really* important things like your thesis can easily be backed up. Heck, that should even be backupable on a DVD, because mine fitted on a 1.44MByte floppy
There's part of the reason that I don't have a regimented backup scheme... a good part of the data that's not easily replacable (at least with a few days to reinstall stuff) is on network drives at school. And believe you me when I say that those *are* backed up... we even have ready access to the previous day's backup at any time in case we delete something important, and apparently can persuade them to go back further if we explicitly request it. So really I would lose three things by not backing up. One is the time it takes to reinstall, two are irreplacable or hard-to-replace stuff that are probably weakly infringing someone's copyrights (like an entire hard drive devoted to Star Trek TNG episodes I recorded off of TV back when I was in the dorms and still had cable; that drive was supposed to mirror another in a RAID array, but apparently the SATA card's manual I have is lying about being able to build an array from an existing disk so I never set that up so had an extra drive), and a good portion of my photos. I should probably back up those photos one of these days... I have a 40 gig in an external USB enclosure that's plugged in RIGHT NOW that I have or could make space on...
The rest I have either on my semesterly backup CDs for really old stuff or school drives.
(You can tell I didn't learn my lesson from when I did have a drive failure... though I got off lucky then because only one partition -- the one I cared about the least, in fact almost not at all -- was unrecoverable. Though that incident did spur me to buy the second drive for the RAID 1 array that never got set up and now has about 85% of TNG.)
You have a number of good questions; here are my thoughts.
Normal APIs don't support extra streams. Getting fopen() to work with streams is a hack, to put it mildly.
This is still *definitely* in the realm of tool support in the way I'm thinking of it. In some sense it's at a higher level, because it makes pepole who are trying to make tools in the first place jump through hoops, which is why it's not *really* in tool support as such. But what I mean by 'tool support' is just... MS introduced these streams but almost no support for using them either as an end user or as a programmer. And I don't know why. It's like there was a disconnect between the peoeple designing NTFS and the people actually implementing, well, everything else. Who knows, perhaps probably there was. More about this in a second.
The notation used on Windows is... interesting. If you are in D:\ with a file called C, does C:foo refer to a stream on D:\C or to a file called foo in the current directory of the C drive?
On a Linux or MacOS system, all characters except '/' and '\0' are valid in filenames, so we have nothing to spare. No, you can't steal the ':'.
These both go together, because they're more or less the same thing. There are two issues here, which is how how streams are treated by APIs, and how the end user sees them. Totally technically, the second point really isn't EVER dictated by the filesystem or OS even now; it's really up to the application, shell, whatever how they show the end user. There are conventions that essentially everyone follows though, and establishing a reasonable convention for how they should be treated I think would be part of the design of this filesystem.
But this leads to the API issue. What should the interface be? I think that an API that takes 'filename:stream' (no matter what the special character is) to open that stream is a badly-designed API. Instead of fopen("foo.txt:bar"), I think it would be better to do something like fopen("foo.txt", "bar"). I don't think there's any more reason for keeping the filename and stream together than any other pair of arguments. This would require changing the system call API though... On Windows, not actually that big of a problem probably since the system call API is independent of the programmer-visible APIs and adding new Windows API functions is clearly not an issue for them, but I guess on Unix there's considerable intertia here. The point of all this is that the only place that special characters would be necessary is from the user's perspective.
And from the user's perspective, there's already often places where we need to do weird things to make file names work. For instance, file names can contain spaces. But 'cat some long file name.txt' isn't going to work, so you have to quote the file name or escape the spaces. In other words, spaces are a special character because they delimit command line arguments in your typical shell. The ability to escape spaces with backslash means that backslash has become a special character. At the very least, a shell that does this needs to distinguish between 'cat file1\ file2' meaning 'cat "file1 file2"' and 'cat "file1\" "file2"'. (Yeah, not legal syntax because the \ escapes the ". Pretend it didn't.) Quotes become special in a similar way. So I don't think there's a big elegance problem with introducing : as a stream separator and requiring it to be escaped if it's part of a filename. I don't exactly remember encountering many file names with ':' in them even though it's allowed, so I think this impact would be minimal to nil. (Though existing stripts and stuff might break; this is a problem.)
Today I can copy a file with the dd command. I can copy a file using the cat command and shell redirection. Multi-forked files would lose data.
This is a good point, though... maybe unimportant? Maybe that's how you want the behavior to go. I don't know.
It looks like you need a directory... why not use one? This is how MacOS X apps w
[storing diffs] doesn't work so well with binary files
.doc files with msword.exe' (or oowriter.exe, or whatever), it could say 'diff .doc files with msworddiff.exe'. The output of msworddiff would then be stored as the diff, and msworddiff would be used to generate old versions*. (Which leads to a big drawback of this approach, which is that you must have the diff engine around when you do that. Maybe MS trying to set a standard -- or even requiring through some signing thing, as many drawbacks as come with that approach -- of releasing these for free, and making them (MS's and 3rd partys') available in an online directory would alleviate this somewhat.) This would allow it to pick up structure from binary data at least a lot of the time.
:-p (Actually that's somewhat tempting me now that I think about it... but I don't have the psych background I probably should.) But I do think that CVS+$(FAVORITE_FILE_SYSTEM) would be pretty sweet, and might even make a noticable change to the way people think and/or treat about files.
This is, of course, true. (OTOH, one reason that I think that 50% overhead for the 100 revisions is VERY VERY overblown is that I have a few binary files in our current repository that aren't part of that 6 MB checkin.)
I'm not sure exactly what a versioning filesystem should do with binary files, but I do think there would have to be something that treated them differently, and I have a few ideas. At the crudest implementation, you could just drop binary files completely, and only version text files. Or do the same thing, but instead of deciding whether to store a new version based on the binaryness of the file, do it based on whether the ratio of the diff is larger than x% of the size of the file itself. You could also just treat them the same during creation, but then favor deleting binary revisions either directly or indirectly when you're looking for space. (When you're garbage collecting essentially, only with a definition of "garbage" that lets you delete old revisions. I also suspect this would be necessary in such a file system.)
One slick idea I thought of would be to allow 3rd party apps to register what you might call a 'diff engine'. In the same way it can say 'open
*Note: I don't know if DOC would benefit as much from this; like I don't know if it would be considered binary or text. But even if it's text data and can be efficienly diffed, the idea still stands I think.
I don't claim to know all of the tradeoffs of how to do this, or how to present versions to the user, or what degree of control to give regarding a lot of these aspects. Maybe there's a Ph.D. thesis here for someone in human factors.
Ah, that makes a lot more sense.