Only if it is implemented as such. It probably isn't.

Suppose you have a file which was modified once (ie there are two versions). The overall filesystem has files which have had 3 billion modifications. You have 3 billion trees and the leaf node for that file in each tree points to one of two versions.

The smart way to search the tree is to compare all the roots and eliminate any which aren't different versions (there won't be any at this level, since new roots are only created for new snapshots). Then you descend one level in each and eliminate all which aren't different versions (which will eliminate 99% of the records at this level, since if you snapshot on a single file change most nodes will be shared across two trees except the one containing the one file that changed). Then you keep going down eliminating duplicates in this way. In the end you'll have a bunch of linked lists from root to leaf showing the one file that changed in each new root (a tree with only one node per level is a linked list). Then you search the leaf nodes for the file of interest and generate a linear history for that one file. If you are targetting a particular file then you can stop your search early on most of those trees anytime you discard the parent of the desired leaf (if you're looking for changes in /etc/passwd and in this tree only an unknown file in /usr changed you can stop searching).

That is still a lot of work, because there was no linkage between file versions in the data structures. A filesystem optimized for file versioning would store a link from each file to the previous version so that the history for a single file could be traversed with only one seek per version.

However, doing this from userspace is going to be even less efficient if the filesystem doesn't expose its internals. In userspace you have no visibility into which directories under a snapshot are a shared record in the filesystem. To trace the history of a single file requires descending to that file in every single tree, and doing a full comparison, which is far more operations than in the optimal algorithm. To trace the history of the entire tree requires comparing every file in every snapshot, which is an enormous number of operations even in RAM, let alone on disk.

If you've ever tried to do a git log on an individual file in a very large git repository you might have noticed this problem, and I believe git does things in the optimal way. (Git repositories are very similar to COW filesystems.) If you stuck your entire hard drive into a git repository and did a commit on every change, you'd quickly run into this problem.

To do this well really requires designing the feature into the filesystem. Doing it in a COW filesystem is especially challenging since if you want to remove a snapshot you need to potentially clean up broken links at the leaf level if you're actually linking across snapshots so that you can easily traverse file histories.

Agree that this is a challenge. It would seem to me that the simplest solution would be to create a version anytime you close the descriptor. I realize that some activities that keep files open for long times would not create versions, but for most mainstream cases it would probably work. It would certainly work better than just taking random snapshots at random times when a file might be half-modified.

A solution does not need to be perfect to be useful.

I suppose, though that still leaves you with the challenge of finding all the versions of a single file. I'm not as familiar with the zfs internals, but I don't believe there are any data structures in btrfs that make it easy to traverse all the versions of a single file.

Well, the whole idea would be to have simple snapshots of every file version without having to re-implement every application I use.

And it sounds like the answer to my second question is no. btrfs works in the same way. The snapshot is at the filesystem/subvolume level, and if you want to find all the versions of a particular file you basically have to find the file in every snapshot that exists and diff them all.

I love btrfs. I just don't think that it solves this particular problem, and neither does any other linux filesystem. The fact that nobody has implemented this on linux doesn't make it any less useful.

He never said he was happy with Windows Server's versioning.

He did mention sharepoint, which does retain a version on every file save.

I'm well aware that zfs and btrfs can be told to snapshot the entire filesystem as often as you want to fire off a cron job.

While I agree in principle and I'd love to see states get rid of marriage legally, I do think that it will take a lot more reworking of laws to make it happen.

For example, in Pennsylvania any number of random people can buy a house together and each own a portion of the property. However, only a married couple can buy it such that they each own 100% of it. The practical difference is that if one property-owner has a lein in the first case, then the lein remains against their share of the property up to the value of that share even if that owner dies. However, in the case of a married couple if one member of the couple has a lein against the house and the other does not, then upon their death the lein does not remain against the house because the other owner already owned 100% of it and the dead owner is simply struck from the deed.

So, there are likely situations where marriage does get special treatment that need to be resolved.

However, I do agree that there isn't any situation handled by marriage that could be legally handled in some other way, and I'd love to see marriage become purely a cultural/religious/etc arrangement with no legal basis at all. You could still have standard contracts for property ownership among couples just as there are standards for contracts for buying/selling houses, and individuals could enter into these or modify them as they see fit.

Can you make it snapshot anytime a file is modified? Also, can you easily find all the snapshots for a single file? Or do you just have 3 million subdirectories where a given file might or might not change between any random pair of them?

Can ZFS actually do versioning on every file close? I know it can do snapshots, but of course btrfs can do that as well. I'd think that the goal of a versioning filesystem would be that versions are captured anytime a file is written, not just when the admin hits the snapshot button, or once an hour, or whatever.

As far as I've seen the COW filesystems only do snapshots when they're asked to, and I'm not sure they're designed to scale to the point where you have billions of snapshots for millions of files.

Isn't that a bit like saying that there were HUNDREDS of programmers involved in combing over every line of that software. Do you really think that it could contain a bug?

You're suggesting that the principle that is the reason that all software contains bugs be the bedrock of jurisprudence?

Perhaps, but the intent of the writer isn't nearly as important as the intent of the congressmen who voted for it, likely not having even read the entire thing.

When you write laws that are hundreds of pages long, it will be like writing software hundreds of pages long, and there will be bugs. The solution to legal "bugs" is to fix them, not pretend we're computers. That is what the court did.

If Congress really intends for Obamacare to go into a death spiral, they can always pass a law to make that happen.

No doubt Apple will use this improvement in high-demand technology to justify a price hike.

I'm not saying it is the right solution, but in many areas the individual is responsible.

If an airline tells a pilot to fly more than the legal number of hours in a week or they're fired, the pilot still loses his license if he complies. Of course, if they instead call the local regulator I suspect the airline will get a nasty visit from an inspector.

Engineers are legally liable if they sign off on an unsound building, regardless of the instructions of their employer.

The EU requires an EU citizen to sign off on the quality of imports of stuff like medical devices and if there is a problem they can go to jail. It is their responsibility to ensure that whoever they're working with is getting audited to ensure they are in compliance.

So, there are many areas of the economy where safety is critical and the solution is to make a particular individual personally criminally liable. It forces the buck to stop somewhere. That person is supposed to get a lot of clout with the regulators as well when they feel they're pressured to cut corners.

I'm well aware that pension funds tend to put their money into stocks. I still don't see them as an end in themselves. There really is no need for private pensions if you have basic income, but certainly I wouldn't ban them. I would tax assets though.

Most modern production involves capital more than labor. Resources tend to be limited, and if you endlessly grow population you end up with tons of unemployed.

Plus, regulating childbirth is actually a way to cut down on welfare spending. The pure-free-market approach would be to require parents to pay for the full cost of raising kids before having them, thus ensuring that kids are never a cost on anybody but their parents. However, I think it would probably make more sense to have a bit more diversity and have society kick in to let more people have kids.

As you point out many some of that existing $3T already goes to social programs, which would be partially redundant. So, the cost wouldn't be quite that high.

However, I'm more than happy to double income taxes to pay for this. I'd lower taxes at the lower income brackets (which gives people more incentive to work), and I'd raise it at the higher brackets (which is where all the money is anyway). The US GDP is $15T - we can afford to pay for food/etc.

I think our priorities are a bit different. I don't really see stocks and property as an end in and of themselves.

But, I'm all for rehab/etc for those with addiction problems. Also, people with nothing to do tend to have kids, and that is definitely something the system couldn't afford, so there would need to be measures to prevent that (if having kids doesn't cost you a lot, you'll tend to have them).