Date: Fri, 05 Feb 2021 19:23:36 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: maintainer-feedback requested: [Bug 253278] x11-servers/xorg-server: Lock file: Various fixes Message-ID: <bug-253278-7141-sbcgQySd5W@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253278-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-253278-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
Bugzilla Automation <bugzilla@FreeBSD.org> has asked freebsd-x11 (Nobody) <x11@FreeBSD.org> for maintainer-feedback: Bug 253278: x11-servers/xorg-server: Lock file: Various fixes https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253278 --- Description --- Several fixes: 1. Create a lock file in the case of an explicitly requested display even if "-displayfd" was specified. This is because, in this case, the server creat= ion process is essentially the same as when "-displayfd" is not specified. The = only difference with the latter case should be that Xorg outputs the passed disp= lay to the display FD (only the display selection logic is bypassed). 2. Properly indicate an unexpected problem with link(2), instead of assuming that a failure always means that the file indeed exists. 3. Workaround for what appears to be a FreeBSD bug (link returns EPERM when hard linking a file whose permissions are the result of creating a file in a directory with sticky bit, although creating a separate copy is perfectly possible). Additional benefit: Simplifies the cumbersome logic, which on PO= SIX systems is unnecessary IMHO (initial lock file creation with O_EXCL is enou= gh to ensure mutual exclusion). Again I'm submitting this here, since upstream seems inactive.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253278-7141-sbcgQySd5W>