灾备CLI存储【免费下载链接】bupVery efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images). Please post problems or patches to the mailing list for discussion (see the end of the README below).项目地址https://gitcode.com/gh_mirrors/bu/bup点击查看免费下载bup cat-file是 bup 备份套件中的一个低级low-level内容提取工具它绕过高层的bup-restore/bup-join封装按/branch/revision/path形式的路径直接从仓库归档中取出普通文件的数据、单条元数据条目或整个目录的.bupm元数据文件并原样输出到标准输出。本文以 bup-cat-file.1.md 手册为核心结合 cat_file.py、vfs.py 的实现与 test-cat-file 测试完整讲解该命令的三种工作模式、路径语法、与bup meta/bup join的配合用法及其底层原理让你能直接用它做数据审计、元数据比对与归档内部结构检查。命令定位归档内容提取的低层通道在 bup 的命令体系中bup cat-file属于“其他命令”见 bup(1) 手册 的 OTHER COMMANDS 一节官方定位是 “Extract archive content”提取归档内容。从 cat_file.py 的 optspec 可以看出它的完整用法bup cat-file [--meta|--bupm] /branch/revision/[path] -- meta print the targets metadata entry (decoded then reencoded) to stdout bupm print the target directorys .bupm file directly to stdout它的设计目标很明确默认模式把path指向的普通文件regular file的真实数据内容以原始字节流输出到标准输出适合重定向到文件或管道交给其他程序处理--meta模式输出与path关联的单条元数据条目解码后重新编码的版本--bupm模式输出与path必须是目录关联的整个.bupm元数据文件原始字节。需要注意cat-file是面向脚本与底层操作的接口它不做恢复路径映射、不重新组织目录树只负责“把归档里的某个对象按路径取出来”。这也决定了它与bup-restore完整恢复和bup-join按对象拼接内容的差异。路径语法/branch/revision/[path]bup cat-file的参数路径必须包含**分支branch与修订revision**两部分。源码中的校验逻辑在 cat_file.pyif not re.match(br/*[^/]/[^/], target): o.fatal(fpath {pm(target)} doesnt include a branch and revision)也就是说形如src/latest/src/foo的路径会被拆解为src分支名即bup save -n src创建的命名分支latest修订标识。latest是 git 风格引用指向该分支最近一次 save也支持mybackup~1这种 git 父提交记法见 bup-join.1.md 的示例src/foo分支内的归档路径相对路径段可省略省略时指向该修订的根。路径解析由 vfs.resolve() 完成cat-file调用时传入了followFalse即如果路径最后一个元素是符号链接不要跟随解析直接返回该链接项。这与bup ls的默认行为一致保证提取到的是归档中记录的原始条目。解析过程中的关键行为还包括路径中若有不存在的段结果里对应项为Nonecat-file会报错cannot access ...并退出沿路径遇到的符号链接包括末尾段默认仍会被解析若符号链接层数过多会抛出类似 ELOOP 的 VFS IOErrorwant_metaTrue时每个结果项尽量携带详细元数据如果项的元数据已丢失item.meta会退化为一个整数 mode。三种工作模式详解--meta与--bupm互斥cat_file.py 会直接拒绝同时使用if opt.bupm and opt.meta: o.fatal(--meta and --bupm are incompatible)默认模式提取普通文件内容不指定任何选项时bup cat-file取出path指向文件的数据并写到 stdout。实现要点cat_file.pyif stat.S_ISREG(mode): with vfs.fopen(repo, leaf_item) as f: for b in chunkyreader(f): out.write(b) else: o.fatal(f{pm(target)} is not a plain file)只有S_ISREG(mode)普通文件才允许提取若目标是目录、符号链接、fifo 等会报is not a plain file错误读取通过 vfs.fopen() 打开_FileReader再用chunkyreader分块写出——这样即使是经过 hashsplit 分块的超大型文件也能以稳定内存流式输出输出走byte_stream(sys.stdout)保证在二进制数据下 stdout 不被文本包装破坏见 io.py。由于内容会原样输出典型用法是重定向$ bup cat-file /foo/latest/somefile somefile-content--meta提取单条元数据条目--meta输出path关联的元数据条目但文档特别提醒它返回的不是归档中.bupm里记录的原始字节而是“解码后重新编码”的版本decoded and then re-encoded。实现位于 cat_file.pyaugmented vfs.augment_item_meta(repo, leaf_item, include_sizeTrue) out.write(augmented.meta.encode())vfs.augment_item_meta() 确保item.meta是一个完整的Metadata实例如果元数据只剩整数 mode就构造一个兼容的“伪造”Metadata当include_sizeTrue时会顺带把缺失的文件大小计算出来补上Metadata.encode()见 metadata.py再将其序列化为标准元数据归档格式输出内容可被bup meta --list直接解析。因此--meta的输出在字节层面未必与原始.bupm中的对应条目一致例如重编码可能导致字段顺序、路径表示或时间戳细节的规范化差异但语义等价。若确实需要原始字节文档给出的替代方案是用--bupm提取父目录的.bupm再在输出中定位相关条目。--bupm提取目录的原始 .bupm 文件.bupm是 bup 为每个被保存目录生成的元数据文件bup metadata存放在该目录对应的 git tree 中。--bupm直接把它以原始字节输出前提是path必须指向目录if not stat.S_ISDIR(mode): o.fatal(f{pm(target)} is not a directory) _, bupm_oid vfs.tree_data_and_bupm(repo, leaf_item.oid) if bupm_oid: with vfs.tree_data_reader(repo, bupm_oid) as meta_stream: out.write(meta_stream.read())vfs.tree_data_and_bupm() 展开 tree若 oid 是 commit 会先取其 tree在条目中查找名字恰为.bupm的子树项并返回其 blob oid若该树没有.bupm例如较旧版本的 bup save或非 bup 写入的 treebupm_oid为None此时命令静默不输出任何内容vfs.tree_data_reader() 返回针对该 oid 的读取器这里读出的是.bupm的完整原始字节流。元数据归档格式与 bup meta 的配合bup cat-file --meta与--bupm的输出都是 bup 元数据归档格式因此最常见的下游处理就是管道给bup meta做展示。bup meta的完整能力见 bup-meta.1.mdbup meta --create (-c)为一批路径创建元数据归档bup meta --list (-t)展示归档中的元数据信息-vvf表示更详细输出并从 stdin 读取bup meta --extract (-x)/--start-extract/--finish-extract把元数据应用到文件系统bup meta --edit改写归档中的 uid/gid/user/group 等字段常用辅助选项-R/--recurse递归、--numeric-ids、--symlinks/--no-symlinks、--paths/--no-paths、-f/--file- 表示 stdin/stdout、-v、-q。因此下面两条命令可以组合出“可读的元数据审计输出”# 查看 /foo/latest/something 这一项元数据的可读列表 $ bup cat-file --meta /foo/latest/something | bup meta -tvvf - # 查看 somedir 目录及其包含的所有条目含子项的元数据 $ bup cat-file --bupm /foo/latest/somedir | bup meta -tvvf -实战示例完整的使用场景场景一提取某个历史版本中的文件内容# 保存一次备份 $ bup init $ bup index src $ bup save -n src --strip-path $(pwd) src # 取回 latest 修订中 src/foo 的内容并落盘 $ bup cat-file src/latest/src/foo cat-foo $ diff -u src/foo cat-foo # 应无差异这正是 test-cat-file 中验证的核心路径cat-file的输出必须与原始文件逐字节一致。场景二提取并比对单条元数据$ bup meta --create --no-paths src/foo src-foo.meta $ bup cat-file --meta src/latest/src/foo cat-foo.meta # 排除 atime 等易变字段后逐行比对 $ bup meta -tvvf src-foo.meta | grep -vE ^atime: src-foo.list $ bup meta -tvvf cat-foo.meta | grep -vE ^atime: cat-foo.list $ diff -u src-foo.list cat-foo.list测试用--no-paths创建参考元数据并与--meta输出比对验证了--meta输出的语义等价性见 test-cat-file。场景三校验 .bupm 原始字节$ bup cat-file --bupm src/latest/src/ bup-cat-bupm $ src_hash$(bup ls -s src/latest/ | cut -d -f 1) $ bupm_hash$(git ls-tree $src_hash | grep -F .bupm | cut -d -f 3 | cut -d -f 1) $ dev/git-cat-tree $bupm_hash git-cat-bupm $ cmp git-cat-bupm bup-cat-bupmtest-cat-file 正是这样做的用git ls-tree从目录 tree 里定位.bupm的 blob oid再用仓库自带的 git-cat-tree 取出原始 blob最后cmp确认与bup cat-file --bupm的输出完全一致——这证明了--bupm返回的是未经过任何重编码的原始字节。与 bup join 的对比何时用哪一个bup cat-file与bup join都能从仓库取内容但分工不同。根据 bup-join.1.mdbup join是bup-split的逆向操作接受任何 git 能识别的引用格式分支名、commit id、tree id、blob id把拆分的对象重新拼接成完整内容也支持-r/--remote从远程仓库默认 SSH取数据。它不关心路径语义只关心对象bup cat-file需要/branch/revision/path的路径语义内部走 vfs 解析能区分文件/目录/符号链接还提供元数据层面的--meta/--bupm能力。一句话总结按对象拿内容用bup join按归档路径拿内容或拿元数据用bup cat-file。前者见 bup-join.1.md 的 tar 管道示例后者就是本文的主线。错误处理与使用约束结合 cat_file.py 与 test-cat-filebup cat-file的失败路径很明确触发条件报错信息未指定目标参数must specify a target指定了多个目标only one target file allowed同时使用--meta与--bupm--meta and --bupm are incompatible路径缺少分支/修订path x doesnt include a branch and revision路径在归档中不存在cannot access /x in x/y退出码 2--bupm指向非目录... is not a directory默认模式指向非普通文件... is not a plain file运行前提必须先有可用的 bup 仓库bup init初始化过因为 cat_file.py 一进来就会执行git.check_repo_or_die()仓库通过LocalRepo()打开。另外两点细节--meta输出是重编码结果需要“字节级一致”时请改用--bupm方案旧版 bup save 或非 bup 创建的 tree 没有.bupm此时--bupm静默输出空。总结bup cat-file是 bup 中面向脚本与深度审计的低层提取工具默认模式以流式方式输出普通文件的原始数据--meta输出解码重编码的单条元数据--bupm输出目录的原始.bupm字节。结合 vfs.py 的路径解析与元数据增强逻辑、metadata.py 的归档格式以及 test-cat-file 对三种模式含字节级一致性的完整验证你可以放心地把它用于备份内容比对、元数据审计和归档结构检查。想继续深入可阅读 bup-meta.1.md 了解元数据归档的完整操作面或通过 bup-join.1.md 掌握按对象拼接内容的另一条路径。赞分享灾备CLI存储【免费下载链接】bupVery efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images). Please post problems or patches to the mailing list for discussion (see the end of the README below).项目地址https://gitcode.com/gh_mirrors/bu/bup点击查看免费下载相关推荐Nix 的 nix nar cat 命令完全指南从 NAR 归档中提取文件内容Nix 的 nix nar cat 命令完全指南从 NAR 归档中提取文件内容 导读 nix nar cat 是 Nix 包管理器中用于 从 Nix Arch包管理器开发工具CLI构建工具Haystack Extractors 组件深度指南NER 实体抽取、LLM 元数据提取与图像文档内容抽取Haystack Extractors 组件深度指南NER 实体抽取、LLM 元数据提取与图像文档内容抽取 本文聚焦 Haystack 开源 AI 编排框架中人工智能大模型RAGAI AgentNLPRufus数据提取终极指南如何快速获取归档文件内容Rufus数据提取终极指南如何快速获取归档文件内容 Rufus作为一款可靠的USB格式化工具The Reliable USB Formatting Util桌面应用开发工具上一篇PyPTO-Gym 中 eye 算子的 kernel 参考骨架full one_hot cast assemble 逐行切分实践下一篇15分钟跑通Gumroad开源电商从零搭一个能收款的创作者商店创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 bup cat-file 深度指南：从 bup 归档中低层提取文件内容、元数据与 .bupm 目录清单
灾备CLI存储【免费下载链接】bupVery efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images). Please post problems or patches to the mailing list for discussion (see the end of the README below).项目地址https://gitcode.com/gh_mirrors/bu/bup点击查看免费下载bup cat-file是 bup 备份套件中的一个低级low-level内容提取工具它绕过高层的bup-restore/bup-join封装按/branch/revision/path形式的路径直接从仓库归档中取出普通文件的数据、单条元数据条目或整个目录的.bupm元数据文件并原样输出到标准输出。本文以 bup-cat-file.1.md 手册为核心结合 cat_file.py、vfs.py 的实现与 test-cat-file 测试完整讲解该命令的三种工作模式、路径语法、与bup meta/bup join的配合用法及其底层原理让你能直接用它做数据审计、元数据比对与归档内部结构检查。命令定位归档内容提取的低层通道在 bup 的命令体系中bup cat-file属于“其他命令”见 bup(1) 手册 的 OTHER COMMANDS 一节官方定位是 “Extract archive content”提取归档内容。从 cat_file.py 的 optspec 可以看出它的完整用法bup cat-file [--meta|--bupm] /branch/revision/[path] -- meta print the targets metadata entry (decoded then reencoded) to stdout bupm print the target directorys .bupm file directly to stdout它的设计目标很明确默认模式把path指向的普通文件regular file的真实数据内容以原始字节流输出到标准输出适合重定向到文件或管道交给其他程序处理--meta模式输出与path关联的单条元数据条目解码后重新编码的版本--bupm模式输出与path必须是目录关联的整个.bupm元数据文件原始字节。需要注意cat-file是面向脚本与底层操作的接口它不做恢复路径映射、不重新组织目录树只负责“把归档里的某个对象按路径取出来”。这也决定了它与bup-restore完整恢复和bup-join按对象拼接内容的差异。路径语法/branch/revision/[path]bup cat-file的参数路径必须包含**分支branch与修订revision**两部分。源码中的校验逻辑在 cat_file.pyif not re.match(br/*[^/]/[^/], target): o.fatal(fpath {pm(target)} doesnt include a branch and revision)也就是说形如src/latest/src/foo的路径会被拆解为src分支名即bup save -n src创建的命名分支latest修订标识。latest是 git 风格引用指向该分支最近一次 save也支持mybackup~1这种 git 父提交记法见 bup-join.1.md 的示例src/foo分支内的归档路径相对路径段可省略省略时指向该修订的根。路径解析由 vfs.resolve() 完成cat-file调用时传入了followFalse即如果路径最后一个元素是符号链接不要跟随解析直接返回该链接项。这与bup ls的默认行为一致保证提取到的是归档中记录的原始条目。解析过程中的关键行为还包括路径中若有不存在的段结果里对应项为Nonecat-file会报错cannot access ...并退出沿路径遇到的符号链接包括末尾段默认仍会被解析若符号链接层数过多会抛出类似 ELOOP 的 VFS IOErrorwant_metaTrue时每个结果项尽量携带详细元数据如果项的元数据已丢失item.meta会退化为一个整数 mode。三种工作模式详解--meta与--bupm互斥cat_file.py 会直接拒绝同时使用if opt.bupm and opt.meta: o.fatal(--meta and --bupm are incompatible)默认模式提取普通文件内容不指定任何选项时bup cat-file取出path指向文件的数据并写到 stdout。实现要点cat_file.pyif stat.S_ISREG(mode): with vfs.fopen(repo, leaf_item) as f: for b in chunkyreader(f): out.write(b) else: o.fatal(f{pm(target)} is not a plain file)只有S_ISREG(mode)普通文件才允许提取若目标是目录、符号链接、fifo 等会报is not a plain file错误读取通过 vfs.fopen() 打开_FileReader再用chunkyreader分块写出——这样即使是经过 hashsplit 分块的超大型文件也能以稳定内存流式输出输出走byte_stream(sys.stdout)保证在二进制数据下 stdout 不被文本包装破坏见 io.py。由于内容会原样输出典型用法是重定向$ bup cat-file /foo/latest/somefile somefile-content--meta提取单条元数据条目--meta输出path关联的元数据条目但文档特别提醒它返回的不是归档中.bupm里记录的原始字节而是“解码后重新编码”的版本decoded and then re-encoded。实现位于 cat_file.pyaugmented vfs.augment_item_meta(repo, leaf_item, include_sizeTrue) out.write(augmented.meta.encode())vfs.augment_item_meta() 确保item.meta是一个完整的Metadata实例如果元数据只剩整数 mode就构造一个兼容的“伪造”Metadata当include_sizeTrue时会顺带把缺失的文件大小计算出来补上Metadata.encode()见 metadata.py再将其序列化为标准元数据归档格式输出内容可被bup meta --list直接解析。因此--meta的输出在字节层面未必与原始.bupm中的对应条目一致例如重编码可能导致字段顺序、路径表示或时间戳细节的规范化差异但语义等价。若确实需要原始字节文档给出的替代方案是用--bupm提取父目录的.bupm再在输出中定位相关条目。--bupm提取目录的原始 .bupm 文件.bupm是 bup 为每个被保存目录生成的元数据文件bup metadata存放在该目录对应的 git tree 中。--bupm直接把它以原始字节输出前提是path必须指向目录if not stat.S_ISDIR(mode): o.fatal(f{pm(target)} is not a directory) _, bupm_oid vfs.tree_data_and_bupm(repo, leaf_item.oid) if bupm_oid: with vfs.tree_data_reader(repo, bupm_oid) as meta_stream: out.write(meta_stream.read())vfs.tree_data_and_bupm() 展开 tree若 oid 是 commit 会先取其 tree在条目中查找名字恰为.bupm的子树项并返回其 blob oid若该树没有.bupm例如较旧版本的 bup save或非 bup 写入的 treebupm_oid为None此时命令静默不输出任何内容vfs.tree_data_reader() 返回针对该 oid 的读取器这里读出的是.bupm的完整原始字节流。元数据归档格式与 bup meta 的配合bup cat-file --meta与--bupm的输出都是 bup 元数据归档格式因此最常见的下游处理就是管道给bup meta做展示。bup meta的完整能力见 bup-meta.1.mdbup meta --create (-c)为一批路径创建元数据归档bup meta --list (-t)展示归档中的元数据信息-vvf表示更详细输出并从 stdin 读取bup meta --extract (-x)/--start-extract/--finish-extract把元数据应用到文件系统bup meta --edit改写归档中的 uid/gid/user/group 等字段常用辅助选项-R/--recurse递归、--numeric-ids、--symlinks/--no-symlinks、--paths/--no-paths、-f/--file- 表示 stdin/stdout、-v、-q。因此下面两条命令可以组合出“可读的元数据审计输出”# 查看 /foo/latest/something 这一项元数据的可读列表 $ bup cat-file --meta /foo/latest/something | bup meta -tvvf - # 查看 somedir 目录及其包含的所有条目含子项的元数据 $ bup cat-file --bupm /foo/latest/somedir | bup meta -tvvf -实战示例完整的使用场景场景一提取某个历史版本中的文件内容# 保存一次备份 $ bup init $ bup index src $ bup save -n src --strip-path $(pwd) src # 取回 latest 修订中 src/foo 的内容并落盘 $ bup cat-file src/latest/src/foo cat-foo $ diff -u src/foo cat-foo # 应无差异这正是 test-cat-file 中验证的核心路径cat-file的输出必须与原始文件逐字节一致。场景二提取并比对单条元数据$ bup meta --create --no-paths src/foo src-foo.meta $ bup cat-file --meta src/latest/src/foo cat-foo.meta # 排除 atime 等易变字段后逐行比对 $ bup meta -tvvf src-foo.meta | grep -vE ^atime: src-foo.list $ bup meta -tvvf cat-foo.meta | grep -vE ^atime: cat-foo.list $ diff -u src-foo.list cat-foo.list测试用--no-paths创建参考元数据并与--meta输出比对验证了--meta输出的语义等价性见 test-cat-file。场景三校验 .bupm 原始字节$ bup cat-file --bupm src/latest/src/ bup-cat-bupm $ src_hash$(bup ls -s src/latest/ | cut -d -f 1) $ bupm_hash$(git ls-tree $src_hash | grep -F .bupm | cut -d -f 3 | cut -d -f 1) $ dev/git-cat-tree $bupm_hash git-cat-bupm $ cmp git-cat-bupm bup-cat-bupmtest-cat-file 正是这样做的用git ls-tree从目录 tree 里定位.bupm的 blob oid再用仓库自带的 git-cat-tree 取出原始 blob最后cmp确认与bup cat-file --bupm的输出完全一致——这证明了--bupm返回的是未经过任何重编码的原始字节。与 bup join 的对比何时用哪一个bup cat-file与bup join都能从仓库取内容但分工不同。根据 bup-join.1.mdbup join是bup-split的逆向操作接受任何 git 能识别的引用格式分支名、commit id、tree id、blob id把拆分的对象重新拼接成完整内容也支持-r/--remote从远程仓库默认 SSH取数据。它不关心路径语义只关心对象bup cat-file需要/branch/revision/path的路径语义内部走 vfs 解析能区分文件/目录/符号链接还提供元数据层面的--meta/--bupm能力。一句话总结按对象拿内容用bup join按归档路径拿内容或拿元数据用bup cat-file。前者见 bup-join.1.md 的 tar 管道示例后者就是本文的主线。错误处理与使用约束结合 cat_file.py 与 test-cat-filebup cat-file的失败路径很明确触发条件报错信息未指定目标参数must specify a target指定了多个目标only one target file allowed同时使用--meta与--bupm--meta and --bupm are incompatible路径缺少分支/修订path x doesnt include a branch and revision路径在归档中不存在cannot access /x in x/y退出码 2--bupm指向非目录... is not a directory默认模式指向非普通文件... is not a plain file运行前提必须先有可用的 bup 仓库bup init初始化过因为 cat_file.py 一进来就会执行git.check_repo_or_die()仓库通过LocalRepo()打开。另外两点细节--meta输出是重编码结果需要“字节级一致”时请改用--bupm方案旧版 bup save 或非 bup 创建的 tree 没有.bupm此时--bupm静默输出空。总结bup cat-file是 bup 中面向脚本与深度审计的低层提取工具默认模式以流式方式输出普通文件的原始数据--meta输出解码重编码的单条元数据--bupm输出目录的原始.bupm字节。结合 vfs.py 的路径解析与元数据增强逻辑、metadata.py 的归档格式以及 test-cat-file 对三种模式含字节级一致性的完整验证你可以放心地把它用于备份内容比对、元数据审计和归档结构检查。想继续深入可阅读 bup-meta.1.md 了解元数据归档的完整操作面或通过 bup-join.1.md 掌握按对象拼接内容的另一条路径。赞分享灾备CLI存储【免费下载链接】bupVery efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images). Please post problems or patches to the mailing list for discussion (see the end of the README below).项目地址https://gitcode.com/gh_mirrors/bu/bup点击查看免费下载相关推荐Nix 的 nix nar cat 命令完全指南从 NAR 归档中提取文件内容Nix 的 nix nar cat 命令完全指南从 NAR 归档中提取文件内容 导读 nix nar cat 是 Nix 包管理器中用于 从 Nix Arch包管理器开发工具CLI构建工具Haystack Extractors 组件深度指南NER 实体抽取、LLM 元数据提取与图像文档内容抽取Haystack Extractors 组件深度指南NER 实体抽取、LLM 元数据提取与图像文档内容抽取 本文聚焦 Haystack 开源 AI 编排框架中人工智能大模型RAGAI AgentNLPRufus数据提取终极指南如何快速获取归档文件内容Rufus数据提取终极指南如何快速获取归档文件内容 Rufus作为一款可靠的USB格式化工具The Reliable USB Formatting Util桌面应用开发工具上一篇PyPTO-Gym 中 eye 算子的 kernel 参考骨架full one_hot cast assemble 逐行切分实践下一篇15分钟跑通Gumroad开源电商从零搭一个能收款的创作者商店创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考