Date: Mon, 9 Feb 2026 16:46:00 +0100 From: Lionel Cons <lionelcons1972@gmail.com> To: Freebsd hackers list <freebsd-hackers@freebsd.org> Subject: Re: Implementing O_SYMLINK in FreeBSD? Message-ID: <CAPJSo4UDuF2TVyqt_Y10o0WqXGx2Cak5Lyqo2HzdRTksuqXcvQ@mail.gmail.com> In-Reply-To: <aYdDGdESyONZja4j@kib.kiev.ua> References: <CAPJSo4VDAb5yPh%2BLV9qDgFPUisuTWk1DhB3boGPenrY3GJo2yQ@mail.gmail.com> <aYZuY2th1CXXAULX@kib.kiev.ua> <86wm0oagde.fsf@ltc.des.dev> <aYdDGdESyONZja4j@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
On Sat, 7 Feb 2026 at 14:50, Konstantin Belousov <kostikbel@gmail.com> wrote: > > On Sat, Feb 07, 2026 at 01:27:09PM +0100, Dag-Erling Smørgrav wrote: > > Konstantin Belousov <kostikbel@gmail.com> writes: > > > Lionel Cons <lionelcons1972@gmail.com> writes: > > > > Would it be possible to implement O_SYMLINK to open a symlink > > > > directly in FreeBSD? > > > What is the semantic, exactly? > > > > You get a file descriptor that represents the symbolic link. You cannot > > read(2) from it or write(2) to it but you can fchflags(2), fchmod(2), > > fchown(2), f[gs]etxattr(2) (their equivalent of extattr_[gs]et_fd(2)), > > fstat(2) etc. and there is an freadlink(2). It can make it easier to > > safely copy symbolic links, or safely extract them from an archive. I > > would love to see it in FreeBSD. > > > > Note that O_SYMLINK is not like O_DIRECTORY; it is not an error to use > > O_SYMLINK when opening something that is not a symbolic link. It just > > means “if the name refers to a link, open the link, not the target”. > > I remember it was already mentioned O_PATH | O_NOFOLLOW as sort of > substitute for the O_SYMLINK. What is the difference with proposed > O_SYMLINK? > > We do not have freadlink(2), but I think it is possible to add the > semantic to readlinkat(2) when dirfd is a symlink opened with O_PATH, > and path is NULL. Unfortunately readlinkat() does not take flags, > with O_EMPTYPATH it would be even natural. Or I can implement > freadlink() as ioctl(2) or fcntl(2). > > Anyway, I think we are almost there with existing facilities. > We are short on bits for openat(2) flags, How many bits are left? > so there is some opposition > against adding new flags unless absolutely required. Win32 FILE_FLAG_OPEN_REPARSE_POINT has been around since over 40 years, and the original VMS flags which are the basis for FILE_FLAG_OPEN_REPARSE_POINT are now almost 50 years old. The API should be pretty simple and stable. Lionelhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPJSo4UDuF2TVyqt_Y10o0WqXGx2Cak5Lyqo2HzdRTksuqXcvQ>