On Sun, May 17, 2026 at 05:35:33PM +1000, Seth McDonald wrote:
The maildir driver uses a file containing the uid database or validity
to keep track of uids. Since dry runs shouldn't modify the actual
maildir store, use of this file should be simulated.
The driver's logic heavily depends on this file, especially when using
a database, so access to it can't simply be prevented.
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.
i'm also not convinced that it's necessary to suppress _all_ writes in
the first place. 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. in fact, opening imap
mailboxes will positively cause the imap server to execute equivalent
steps as far as necessary.
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.
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
