On Wed, 20 May 2026 at 13:38:14 +0200, Oswald Buddenhagen wrote: > On Tue, May 19, 2026 at 01:37:11PM +1000, Seth McDonald wrote: > > 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. > > > huh?
That was a pretty poor explanation - my bad. When opening the uid database/validity file in a real run, the program opens the file if it exists, otherwise creates it if possible, and otherwise fails. If we were to simulate this in a dry run, we would need to mimic this success/failure logic. A possible situation here is where in a real run the parent directory for the uid file was previously created with mkdir_p(), meaning opening the file fails but creating it succeeds. While on a dry run if mkdir_p() only simulates the directory creation, the parent dir would not exist, so both opening and creating the file would fail. Using a temporary copy smoothly handles this. Create the temporary file. If we can open the uid file, copy its contents. Otherwise if the parent dir has write perms, do nothing. Otherwise fail. The result is analogous to the real run. > > Then this should be _explicitly_ mentioned in the manual. > > > fair. proposed rewritten version: > > Enter simulation mode: the Channel status is queried and all required > operations are determined, but no synchronization is actually performed. > Note that this does not imply completely read-only operation, as > mailbox book-keeping is still performed by the drivers. I wouldn't mention drivers since that's an implementation detail the user wouldn't know about. But otherwise the gist definitely better describes the current behaviour. > > Suppose [...] > > > ?!? > https://datatracker.ietf.org/doc/html/rfc9051#name-unique-identifier-uid-messa Okay, that makes more sense. I figured UIDs would be constant, but thought you implied they could be mutable when you wrote > > > in fact, opening imap mailboxes will positively cause the > > > imap server to execute equivalent steps as far as necessary. Thanks for the clarification. That said, since the UID data shouldn't change between a dry and real run, is there any technical reason why we can't have the dry run operate read-only on the uid database/validity file? Take care, Seth McDonald. -- E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51 _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
