On Sun, Oct 08, 2006 at 10:28:06PM -0400, Jonathan Edwards wrote: > On Oct 8, 2006, at 21:40, Wee Yeh Tan wrote: > >On 10/7/06, Ben Gollmer <[EMAIL PROTECTED]> wrote: > >>Hmm, what about file.txt -> ._file.txt.1, ._file.txt.2, etc? If you > >>don't like the _ you could use @ or some other character. > > > >It does not matter which delimiter you use. I still want my "for i in > >*; do ..." to work as per now.
.<prefix> might be acceptable, but I rubs me the wrong way because of this: > >We want to differentiate files that are created intentionally from > >those that are just versions. If files starts showing up on their > >own, a lot of my scripts will break. Still, an FV-aware > >shell/program/API can accept an environment setting that may quiesce > >the version output. E.g. "export show-version=off/on". Exactly. > if we're talking implementation - i think it would make more sense to > store the block version differences in the base dnode itself rather than > creating new dnode structures to handle the different versions. You'd > then structure different tools or flags to handle the versions (copy > them > to a new file/dnode, etc) - standard or existing tools don't need to > know > about the underlying versions. You're arguing for treating FV as extended/named attributes :) I think that'd be the right thing to do, since we have tools that are aware of those already. Of course, we're talking about somewhat magical attributes, but I think that's fine (though, IIRC, NFSv4 [RFC3530] has some strange verbiage limiting attributes to "applications"). Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
