You're still being really vague on your requirements. Sometimes you talk about a filesystem that can't be modified after it has been written, and other times you talk about a filesystem that can be updated, but only to add information. Sometimes you talk about a read-only restriction that is effective against the superuser (not possible) and other times say that it's OK if the superuser can modify the filesystem without a trace. In addition to new ext3 features, using isofs, and chattr, mounting read-only and using file permissions also effect read-only status, and you'd have to explain how any of these don't meet your requirements. But rest assured that none of them is effective against the superuser.I couldn't tell what "it" is in this sentence, or what checksums you're thinking of. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Linus Torvalds | Linux 2.6.27-rc5 |
| Jared Hulbert | [PATCH 00/10] AXFS: Advanced XIP filesystem |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Linus Torvalds | Linux 2.6.27-rc8 |
git: | |
| David Miller | [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Mark McLoughlin | [PATCH] bridge: make bridge-nf-call-*tables default configurable |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
