On Tue, May 19, 2026 at 12:31:51PM +1000, Seth McDonald wrote:
On Mon, 18 May 2026 at 10:42:47 +0200, Oswald Buddenhagen via isync-devel wrote:
dry run doesn't need
to ensure that a real run would actually succeed.
Strong disagree.
What are the reasons users would want to dry run a program? There's
curiosity (what will this do?), assurance (will this do what I want?),
and - most importantly - checking for potential problems in a safe and
non-destructive environment.
deferring an error report about an unwritable directory to a real
run doesn't make it any less safe. it's arguably a tiny bit less useful,
but one has to consider the trade-off between implementation complexity
and covering corner cases (unlikely and little practical impact).
- opening the directory and the subsequent faccessat() seem rather
over-engineered to me. a simple access() would be good enough in this
situation.
access() performs permission checks using the process' real user/group
IDs, which may be different to its effective user/group IDs.
no, they can't. mbsync isn't a setuid program. there is no security
boundary here, and therefore no security-sensitive race condition.
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
