除了在 "
Git: fatal: fsync error on 'sha1 file': Bad file descriptor" 中提到的所有权/驱动器映射问题之外，您实际上可以知道哪个文件有问题。
创建松散对象文件时，我们没有报告我们无法完成
fsync的确切文件名，即使这些信息是可以轻松获取的，但这已经在 Git 2.36（2022年第二季度）中得到了纠正。
查看
提交 c4e707f（2022年3月30日），作者为
Neeraj Singh（neerajsi-msft）。
（由Junio C Hamano -- gitster --合并于提交 98f6a3a，2022年4月4日）
报告者：Ævar Arnfjörð Bjarmason
签署者：Neeraj Singh
如果我们在尝试同步松散的对象文件时死机，请传递我们正在尝试同步的实际文件名。
这对于试图诊断失败原因的用户来说可能更有帮助，而不是以前的“松散对象文件”字符串。
它还避免了将松散对象与具有实际路径的其他内容的die消息翻译不同的任何问题。
fatal: fsync error on 'loose object file': Bad file descriptor
但是（Git 2.36+，2022年第二季度）：
fatal: fsync error on 'path/to/file': Bad file descriptor
此外，自 Git 2.36（2022 年第二季度）起，您可以使用 trace2 添加更多细节，
trace2 代码已经学会报告
fsync 操作的统计信息。请参见
commit 9a49876（2022 年 3 月 30 日），由
Neeraj Singh (neerajsi-msft) 提交。(
已由 Junio C Hamano -- gitster -- 合并至 commit fe496dc，2022 年 4 月 4 日)
trace2: 为 fsync 操作添加统计信息
签署者：Neeraj Singh
添加一些全局的 trace2 统计信息，用于记录 Git 进程生命周期内执行的
fsyncs 数量。这些统计信息将作为
trace2_cmd_exit_fl 的一部分打印出来，我们可能还想在此处打印其他跨领域的统计信息。
fsync the_repository fsync/writeout-only count_fsync_writeout_only
fsync the_repository fsync/hardware-flush count_fsync_hardware_flush
Git 2.38（2022年第三季度）现在在其值全部为零时省略与fsync相关的trace2条目。
请参见
commit 3a251ba（2022年7月18日），作者是
Ævar Arnfjörð Bjarmason（avar）。
（由Junio C Hamano -- gitster --于commit 7c7719a，2022年7月27日合并）
trace2: 只有在我们调用
git_fsync() 时才包含 "
fsync" 事件。
签名：Ævar Arnfjörð Bjarmason
修复在
9a49876中添加的过度冗长的trace2日志（“
trace2: add stats for fsync operations”，2022年3月30日，Git v2.36.0-rc0 -
merge）（首次发布于v2.36.0）。自那时起，每个"
git"命令调用都包括这些"data"事件，尽管我们只会在
core.fsyncMethod=batch下使用这些事件，并且即使我们将对象数据写入磁盘，也只有非零值。请参见
c0f4752（“
core.fsyncmethod: batched disk flushes for loose-objects”，2022年4月4日，Git v2.37.0-rc0 --
merge列在
batch #7中）了解该功能。由于我们需要缩进
trace2_data_intmax()行，因此让我们引入辅助变量以确保我们的结果行不会超过CodingGuidelines的建议。这要求将它们包装两次或引入短暂的一次性变量名称，我们选择后者。结果是例如“
git version”
（man）之前会发出总共6个带有
GIT_TRACE2_EVENT目标（版本、开始、
cmd_ancestry、
cmd_name、退出、atexit）的trace2事件，但之后会发出8个。我们在“退出”事件之前会发出2个"data"事件。我们没有发现这一点的原因是
a15860d中添加的trace2单元测试（
trace2: t/helper/test-trace2，2019年2月22日，Git v2.22.0-rc0 --
merge列在
batch #2中）将不关心的任何"data"事件都省略了。让我们使trace2测试更加严格，并在“
t/t0212/parse_events.perl”中进一步附加任何我们不知道的新事件类型。由于我们只调用“
test-tool trace2”，因此不能保证我们将来不会记录其他过度冗长的事件，但我们至少会注意到每次使用trace2的JSON目标记录任何内容时是否开始发出问题事件。我们排除了“data_json”事件类型，否则我们会因
353d3d7中添加的日志（“
trace2: collect Windows-specific process information”，2019年2月22日，Git v2.22.0-rc0 --
merge列在
batch #2中）而在“win测试”和“win+VS测试”CI上失败。看起来那个日志应该真正使用
trace2_cmd_ancestry()，而后者是在
2f732bf中引入的（“
tr2: log parent process name”，2021年7月21日，Git v2.34.0-rc0 --
merge列在
batch #1中），但现在我们先不管它。需要对
aaf8122进行修复（“
unpack-objects: use
stream_loose_object() to unpack large objects”，2022年6月11日，Git v2.38.0 --
merge列在
batch #3中），因为我们正在更改如上所述的这些事件的行为。由于我们总是发出“hardware-flush”事件，因此在
aaf8122中添加的测试并没有测试除了无条件记录该trace2数据之外的任何内容。即使“
core.fsyncMethod