linux系统无统一同步冲突日志，冲突日志由具体工具（如rsync、syncthing、unison）自行生成并存放于各自指定路径；rsync需用--dry-run等参数主动捕获线索，而syncthing和unison才具备真正的冲突检测与标记能力。
同步任务冲突日志不存在于统一位置
Linux 本身不记录“文件同步任务冲突”的独立日志——因为所谓“冲突”不是内核或通用文件系统主动检测并上报的事件，而是具体同步工具（如 rsync、unison、syncthing 或自定义脚本）在执行时遇到逻辑矛盾（如两边同时修改同一文件、权限不一致、删除 vs 修改等）后，由该工具自行判断并输出的结果。没有统一的 /var/log/sync.conflicts 这种文件。
rsync 同步失败时如何捕获冲突线索
rsync 默认不认为“目标已存在不同内容”是错误，它会直接覆盖（除非用 --ignore-existing 或 --update）。真正在意“冲突”的行为需靠参数触发或事后比对：
- 加
--dry-run+-i（itemize）可预览哪些文件会被传输、跳过或删除，输出中表示本地更新、<code>>表示远程更新、c表示内容变化、U表示跳过（因时间戳/大小未变）——这些符号是判断潜在冲突的第一手依据 - 若用
--delete，删前不会警告；但加上--dry-run可看到将被删除的文件列表，避免误删 - 务必重定向 stdout/stderr：运行
rsync -av --dry-run src/ dst/ 2>&1 | tee rsync-preview.log，否则实时输出一刷就没了 - 注意：
rsync不生成结构化冲突日志，所有“冲突相关输出”都在终端或你重定向的文本里，且仅限本次运行
syncthing 或 unison 才有真正的冲突标记与日志
这类双向同步工具会主动检测并标记冲突，其日志路径和行为差异大：
-
syncthing把冲突文件重命名为filename.sync-conflict-20260709-142345并存放在原目录；它的 Web UI “Events” 页面或日志（默认~/.config/syncthing/logs/下的log-*.txt）里会出现CONFLICT字样条目 -
unison在交互模式下遇到冲突会暂停并提示；非交互模式（-auto）则依赖-prefer或-conflict参数决定行为，冲突详情只写入其日志文件（由-logfile指定），例如unison profile-name -logfile /tmp/unison.log - 两者都不会把冲突日志塞进
journalctl或/var/log/——必须查各自配置指定的日志路径，且日志默认不开启，需显式启用
别指望 journalctl 或 dmesg 查同步冲突
系统级日志工具无法告诉你 rsync 是否覆盖了不该覆盖的文件，也不会记录 syncthing 的文件名冲突决策过程：
-
journalctl -u syncthing只显示服务启停、监听端口、panic 等运行状态，不含文件级操作细节 -
dmesg关注硬件、驱动、内存错误，和应用层同步逻辑完全无关 - 真正有用的线索永远在同步工具自己的输出里——要么是 stdout/stderr 实时流，要么是它配置的专用日志文件
- 如果没开日志、没重定向、也没用带冲突检测的工具，那“冲突”就真的没留下任何痕迹
最易被忽略的一点：多数同步工具默认静默运行，不报错也不记冲突。是否能“查看冲突日志”，首先取决于你有没有让工具进入冲突感知模式，并明确指定了日志落盘位置。
