--- Begin Message ---
(Apologies for the re-send; I replied to the wrong message lol.)
On Mon, 18 May 2026 at 11:12:04 +0200, Oswald Buddenhagen via isync-devel wrote:
> i (re-)wrote that code a quarter century ago and haven't re-checked now, but
> intuitively i'd say that this is a spurious claim. there shouldn't be more
> than a handful locations that need to be neutralized to prevent writes, and
> actual operation is in-memory anyway. it's possible that the rescan logic
> would go entirely haywire, but it's only triggered by failing writes, so
> this should be a non-issue.
This is entirely possible. I got the impression it was ingrained due to
the several calls to db->get/put/sync/etc. across drv_maildir.c. And
figured it would be clean to simply open the DB at a temporary file than
to add conditionals at each db->... call.
I should also mention another motiviating reason for the "copy file"
method was that it nicely handles the situation in which a path is
expected to exist due to calling mkdir_p() earlier, but doesn't due to
its dry run path being taken. By simply creating a temporary file in
"/tmp/..." or wherever, the dry behaviour accurately mimics the real
behaviour due to leaving the file empty rather than failing.
> i'm also not convinced that it's necessary to suppress _all_ writes in the
> first place.
See my previous reply's discussion on dry runs and persistent state.
> dry-run is supposed to suppress the actual synchronization, but
> where does it say that the uid assignment logic needs to be suppressed? the
> manual says that mailboxes are not modified, but that refers to the syncable
> high-level state.
Then this should be _explicitly_ mentioned in the manual. When I read
the current man page's description of --dry-run, I would expect that all
filesystem content relating to the local store is identical before and
after running mbsync (other than access times and the like).
> in fact, opening imap mailboxes will positively cause the
> imap server to execute equivalent steps as far as necessary.
Which mbsync should be able to handle. Suppose I have computers A and B
which both use mbsync to synchronise their local mailbox with the same
IMAP store. If computer A synchronises and the IMAP server modifies UID
data in the process, then computer B should be able to handle the
different state when it synchronises later.
The same should apply for dry runs. If a dry run causes the server to
execute steps which change the UID state, a later real run should be
able to handle this.
> on a "philosophical" level, it's an oxymoron to copy (write) a file to ..
> prevent writes. it's obviously a different file, but it feels deeply unclean
> anyway.
The point is to prevent _persistent_ writes. You're still writing to a
file, yes, but those writes will not effect later runs.
Take care,
Seth McDonald.
--
E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51
--- End Message ---
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
