| 1 | | Here's why I don't like uid and gid in here the way they currently are in here. This is kind of like Daira's complaint about falling between two stools. It might be cool to store extra information if it were unambiguously interpretable. For example, maybe if you had uid, gid, and "UUID of the disk partition from which the root filesystem was loaded", then you would later be able to tell (in a hypothetical future "restore" command) whether the stored uid and gid could be meaningfully copied back into the target of the restore. Or maybe that wouldn't work, I don't know. Maybe instead you need to store a copy of the {{{/etc/passwd}}} and {{{/etc/groups}}} so that you can check whether the target system has a sufficiently similar entry in its files as the source system had, for this uid and gid? But in any case I don't like "floating pieces of data which have broken from their anchors", because you can never safely re-anchor them, except by guessing or by asking a human user to guess. To me, uid and gid numbers without any way to recognize their context are that sort of "floating pieces of data". I know it's the Unix Way, but that doesn't mean I have to like it. Also, that tradition originated in a context where you might reasonably expect the sysadmin to write down what he needs to recognize their context (i.e. the name of the system from which this tarball was produced), and that's less true — at least in my experience — for the way {{{tahoe backup}}} is used. |
| | 1 | Here's why I don't like uid and gid in here the way they currently are in here. This is kind of like Daira's complaint about falling between two stools. It might be cool to store extra information if it were unambiguously interpretable. For example, maybe if you had uid, gid, and "UUID of the disk partition from which the root filesystem was loaded", then you would later be able to tell (in a hypothetical future "restore" command) whether the stored uid and gid could be meaningfully copied back into the target of the restore. Or maybe that wouldn't work, I don't know. Maybe instead you need to store a copy of the {{{/etc/passwd}}} and {{{/etc/groups}}} so that you can check whether the target system has a sufficiently similar entry in its files as the source system had, for this uid and gid? But in any case I don't like "floating pieces of data which have broken from their anchors", because you can never safely re-anchor them, except by guessing or by asking a human user to guess. To me, uid and gid numbers without any way to recognize their context are that sort of "floating pieces of data". I know it's the Unix Way, but that doesn't mean I have to like it. Also, that tradition originated in a use-case where you might reasonably expect the sysadmin to write down what he needs to recognize their context (i.e. the name of the system from which this tarball was produced), and that's less true — at least in my experience — for the way {{{tahoe backup}}} is used. |
