fix(cmd,csync): don't silently ignore a missing --exclude file - #10283
Conversation
0174b7b to
71221a6
Compare
71221a6 to
6122b6f
Compare
|
/backport to stable-34.0 |
nextcloudcmd's ExcludedFiles::reloadExcludeFiles() dropped a registered exclude file from the list without any warning when QFile::exists() returned false, and still reported success. A mistyped or unresolved --exclude path (e.g. a relative path that resolves differently under cron than interactively) therefore made nextcloudcmd sync everything with zero exclusions and no diagnostic in the log. - csync_exclude.cpp: log a qWarning when a registered exclude file can't be found, instead of silently erasing it. - cmd.cpp: fail fast with qFatal when a user-supplied --exclude path doesn't exist, instead of only discovering it deep inside reloadExcludeFiles() with no way to distinguish "path is wrong" from "path was never wrong to begin with". Fixes nextcloud#4621 Signed-off-by: mosandlt <[email protected]>
6122b6f to
120fe44
Compare
|
Artifact containing the AppImage: nextcloud-appimage-pr-10283.zip Digest: To test this change/fix you can download the above artifact file, unzip it, and run it. Please make sure to quit your existing Nextcloud app and backup your data. |
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
3 participants
Summary
Fixes #4621.
nextcloudcmd --exclude <path>silently produced a full, unfiltered sync (no exclusions applied) whenever<path>couldn't be resolved at runtime — with no warning or error anywhere. This matches the original report in #4621 exactly: "It still syncs everything... doesn't respect the local exclude list", with nothing in the logs pointing at why.Root cause
ExcludedFiles::reloadExcludeFiles()insrc/csync/csync_exclude.cppiterates the registered exclude-file paths and, whenQFile::exists()isfalsefor one of them, just erases it from the list and moves on —successstaystrue, nothing is logged. This is inconsistent with the sibling branch a few lines below, which doesqWarning()+success = falsewhen a file exists but can't be opened.Because
nextcloudcmd's CLI-level check insrc/cmd/cmd.cpponly tests!options.exclude.isEmpty()(i.e. "was --exclude given at all"), not whether the path actually resolves, any path that doesn't exist at the momentreloadExcludeFiles()runs (typo, cron job with a different CWD than an interactive shell, file not yet materialized, etc.) is dropped without a trace, and the sync proceeds as if--excludehad never been passed.Fix
csync_exclude.cpp: log aqWarning()when a registered exclude file can't be found, instead of silently erasing it — makes the situation visible in--logdebugoutput for all callers (GUI and CLI).cmd.cpp: since a user explicitly passing--exclude <path>clearly intends for that file to be used, fail fast withqFatal()right when parsing the CLI options if the path doesn't exist, rather than only discovering the problem three layers down with no way to tell "user typo" apart from "path was never wrong to begin with".Test plan
reloadExcludeFiles()/loadExcludeFilePatterns()call paths to confirm the silent-drop behavior and that the fix doesn't change behavior for the legitimately-optional system exclude list (still noqFatal, only aqWarning).nextcloudcmd --exclude /nonexistent/path ...before/after the fix.