[PATCH v2 0/2] Document EFTYPE error code and OPENAT2_REGULAR flag

[PATCH v2 0/2] Document EFTYPE error code and OPENAT2_REGULAR flag

[Dorjoy Chowdhury]

Hi,
I am the author of the patch series that adds OPENAT2_REGULAR flag support
for the openat2 system call. The patch series has been picked up in the
vfs-7.2.openat.regular branch of the vfs/vfs.git tree. Hopefully, it will
make it to linux 7.2 without problems. I wanted to send the man page changes
beforehand. I can ping when/if the patches make it to the linux kernel and
then we can merge the man page changes. Thanks!

patch URL: https://lore.kernel.org/linux-fsdevel/20260328172314.45807-1-dorjoychy111@gmail.com/
applied mail: https://lore.kernel.org/linux-fsdevel/20260416-abgraben-seeweg-a44ce660957f@brauner/

Changes in v2:
- new commit documenting EFTYPE error code (review by: Alejandro Colomar <alx@kernel.org>)
- use semantic newline (review by: Alejandro Colomar <alx@kernel.org>)
- use B instead of BR  (review by: Alejandro Colomar <alx@kernel.org>)
- v1 is at: https://lore.kernel.org/linux-man/20260425134048.62616-1-dorjoychy111@gmail.com/

Regards,
Dorjoy

Dorjoy Chowdhury (2):
  man/man3/errno.3: Document EFTYPE error code
  man/man2/openat2.2: Document OPENAT2_REGULAR flag

 man/man2/openat2.2 | 20 ++++++++++++++++++++
 man/man3/errno.3   |  3 +++
 2 files changed, 23 insertions(+)

-- 
2.53.0

[PATCH v2 1/2] man/man3/errno.3: Document EFTYPE error code

[Dorjoy Chowdhury]

Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
---
 man/man3/errno.3 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/man/man3/errno.3 b/man/man3/errno.3
index a070dabca..ed3578b07 100644
--- a/man/man3/errno.3
+++ b/man/man3/errno.3
@@ -590,6 +590,9 @@ Invalid cross-device link (POSIX.1-2001).
 .TP
 .B EXFULL
 Exchange full.
+.TP
+.B EFTYPE
+Wrong file type for the intended operation.
 .SH NOTES
 A common mistake is to do
 .P
-- 
2.53.0

[PATCH v2 2/2] man/man2/openat2.2: Document OPENAT2_REGULAR flag

[Dorjoy Chowdhury]

Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
---
 man/man2/openat2.2 | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/man/man2/openat2.2 b/man/man2/openat2.2
index f0770f3a0..ea3d9ac7b 100644
--- a/man/man2/openat2.2
+++ b/man/man2/openat2.2
@@ -133,6 +133,20 @@ argument,
 .BR openat2 ()
 returns an error if unknown or conflicting flags are specified in
 .IR how.flags .
+.IP
+.BR openat2 ()
+also supports the below additional flags:
+.RS
+.TP
+.BR OPENAT2_REGULAR " (since Linux 7.2)"
+Only open the file specified by
+.I path
+if it is a regular file.
+If it is not a regular file,
+.BR openat2 ()
+fails with the error
+.BR EFTYPE .
+.RE
 .TP
 .I mode
 This field specifies the
@@ -471,6 +485,12 @@ and an escape from the root during path resolution was detected.
 contains
 .BR RESOLVE_NO_XDEV ,
 and a path component crosses a mount point.
+.TP
+.B EFTYPE
+.I how.flags
+contains
+.B OPENAT2_REGULAR
+flag and the path is not a regular file.
 .SH STANDARDS
 Linux.
 .SH HISTORY
-- 
2.53.0

Re: [PATCH v2 1/2] man/man3/errno.3: Document EFTYPE error code

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

[CC += libc-alpha]

Hi Dorjoy,

On 2026-04-26T17:14:25+0600, Dorjoy Chowdhury wrote:
> Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>

Thanks!

	Reviewed-by: Alejandro Colomar <alx@kernel.org>

I will wait until glibc adds this error code to their <errno.h> before
applying the patch.  This means either you should write and send a patch
to glibc (if so, please CC me), or you should ask them to add it
themselves (if you're not comfortable writing glibc code).


Have a lovely day!
Alex

> ---
>  man/man3/errno.3 | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/man/man3/errno.3 b/man/man3/errno.3
> index a070dabca..ed3578b07 100644
> --- a/man/man3/errno.3
> +++ b/man/man3/errno.3
> @@ -590,6 +590,9 @@ Invalid cross-device link (POSIX.1-2001).
>  .TP
>  .B EXFULL
>  Exchange full.
> +.TP
> +.B EFTYPE
> +Wrong file type for the intended operation.
>  .SH NOTES
>  A common mistake is to do
>  .P
> -- 
> 2.53.0
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/2] man/man2/openat2.2: Document OPENAT2_REGULAR flag

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

Hi Dorjoy,

On 2026-04-26T17:14:26+0600, Dorjoy Chowdhury wrote:
> Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>

	Reviewed-by: Alejandro Colomar <alx@kernel.org>

Thanks!  Please ping when it's in Linus's tree, so that I'll merge.


Cheers,
Alex

> ---
>  man/man2/openat2.2 | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/man/man2/openat2.2 b/man/man2/openat2.2
> index f0770f3a0..ea3d9ac7b 100644
> --- a/man/man2/openat2.2
> +++ b/man/man2/openat2.2
> @@ -133,6 +133,20 @@ argument,
>  .BR openat2 ()
>  returns an error if unknown or conflicting flags are specified in
>  .IR how.flags .
> +.IP
> +.BR openat2 ()
> +also supports the below additional flags:
> +.RS
> +.TP
> +.BR OPENAT2_REGULAR " (since Linux 7.2)"
> +Only open the file specified by
> +.I path
> +if it is a regular file.
> +If it is not a regular file,
> +.BR openat2 ()
> +fails with the error
> +.BR EFTYPE .
> +.RE
>  .TP
>  .I mode
>  This field specifies the
> @@ -471,6 +485,12 @@ and an escape from the root during path resolution was detected.
>  contains
>  .BR RESOLVE_NO_XDEV ,
>  and a path component crosses a mount point.
> +.TP
> +.B EFTYPE
> +.I how.flags
> +contains
> +.B OPENAT2_REGULAR
> +flag and the path is not a regular file.
>  .SH STANDARDS
>  Linux.
>  .SH HISTORY
> -- 
> 2.53.0
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/2] man/man2/openat2.2: Document OPENAT2_REGULAR flag

[Dorjoy Chowdhury]

Hey Alex,

On Sun, Apr 26, 2026 at 7:03 PM Alejandro Colomar <alx@kernel.org> wrote:
>
> Hi Dorjoy,
>
> On 2026-04-26T17:14:26+0600, Dorjoy Chowdhury wrote:
> > Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
>
>         Reviewed-by: Alejandro Colomar <alx@kernel.org>
>
> Thanks!  Please ping when it's in Linus's tree, so that I'll merge.
>

Thanks for reviewing. I should ping after it's in Linus's tree,
meaning if it's in Linux 7.2 or Linux 7.2-rc1 ? Sorry I don't quite
know the workflow. Also I guess I need to look into glibc after it
gets into Linus's tree, right?

Regards,
Dorjoy

Re: [PATCH v2 2/2] man/man2/openat2.2: Document OPENAT2_REGULAR flag

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Hey Dorjoy,

On 2026-04-26T23:39:29+0600, Dorjoy Chowdhury wrote:
> Hey Alex,
> 
> On Sun, Apr 26, 2026 at 7:03 PM Alejandro Colomar <alx@kernel.org> wrote:
> >
> > Hi Dorjoy,
> >
> > On 2026-04-26T17:14:26+0600, Dorjoy Chowdhury wrote:
> > > Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
> >
> >         Reviewed-by: Alejandro Colomar <alx@kernel.org>
> >
> > Thanks!  Please ping when it's in Linus's tree, so that I'll merge.
> >
> 
> Thanks for reviewing. I should ping after it's in Linus's tree,
> meaning if it's in Linux 7.2 or Linux 7.2-rc1 ?

-rc1 should be fine.  If anything is eventually reverted, we can fix it
here; no problem.

> Sorry I don't quite
> know the workflow.


> Also I guess I need to look into glibc after it
> gets into Linus's tree, right?

I guess once it's in -rc1, you can start discussing a patch there.
I guess they won't merge anything until it's in the final release, but
you could discuss it earlier, so that it lands there soon after
Linux 7.2.


Have a lovely night!
Alex

> 
> Regards,
> Dorjoy

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 1/2] man/man3/errno.3: Document EFTYPE error code

[Florian Weimer]

* Alejandro Colomar:

> [CC += libc-alpha]
>
> Hi Dorjoy,
>
> On 2026-04-26T17:14:25+0600, Dorjoy Chowdhury wrote:
>> Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
>
> Thanks!
>
> 	Reviewed-by: Alejandro Colomar <alx@kernel.org>
>
> I will wait until glibc adds this error code to their <errno.h> before
> applying the patch.  This means either you should write and send a patch
> to glibc (if so, please CC me), or you should ask them to add it
> themselves (if you're not comfortable writing glibc code).

I'm not sure where this is coming from.  POSIX says EFTYPE was rejected
in favor of ENOTTY.

Thanks,
Florian

Re: [PATCH v2 1/2] man/man3/errno.3: Document EFTYPE error code

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

Hi Florian,

On 2026-04-27T12:34:30+0200, Florian Weimer wrote:
> * Alejandro Colomar:
> 
> > [CC += libc-alpha]
> >
> > Hi Dorjoy,
> >
> > On 2026-04-26T17:14:25+0600, Dorjoy Chowdhury wrote:
> >> Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
> >
> > Thanks!
> >
> > 	Reviewed-by: Alejandro Colomar <alx@kernel.org>
> >
> > I will wait until glibc adds this error code to their <errno.h> before
> > applying the patch.  This means either you should write and send a patch
> > to glibc (if so, please CC me), or you should ask them to add it
> > themselves (if you're not comfortable writing glibc code).
> 
> I'm not sure where this is coming from.

Here's a link to the thread:
<https://lore.kernel.org/linux-man/20260426111707.36541-1-dorjoychy111@gmail.com/T/>

> POSIX says EFTYPE was rejected
> in favor of ENOTTY.

Could you please share a link to that?

Anyway, I guess ENOTTY would be inappropriate in this case.  Although
maybe a better error code could be devised; I don't know.  This is why
I wanted glibc involved in this discussion before this arrives to a
Linux release.  Thanks for the quick feedback!


> Thanks,
> Florian

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 1/2] man/man3/errno.3: Document EFTYPE error code

[Florian Weimer]

* Alejandro Colomar:

> Hi Florian,
>
> On 2026-04-27T12:34:30+0200, Florian Weimer wrote:
>> * Alejandro Colomar:
>> 
>> > [CC += libc-alpha]
>> >
>> > Hi Dorjoy,
>> >
>> > On 2026-04-26T17:14:25+0600, Dorjoy Chowdhury wrote:
>> >> Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
>> >
>> > Thanks!
>> >
>> > 	Reviewed-by: Alejandro Colomar <alx@kernel.org>
>> >
>> > I will wait until glibc adds this error code to their <errno.h> before
>> > applying the patch.  This means either you should write and send a patch
>> > to glibc (if so, please CC me), or you should ask them to add it
>> > themselves (if you're not comfortable writing glibc code).
>> 
>> I'm not sure where this is coming from.
>
> Here's a link to the thread:
> <https://lore.kernel.org/linux-man/20260426111707.36541-1-dorjoychy111@gmail.com/T/>
>
>> POSIX says EFTYPE was rejected
>> in favor of ENOTTY.
>
> Could you please share a link to that?
>
> Anyway, I guess ENOTTY would be inappropriate in this case.  Although
> maybe a better error code could be devised; I don't know.  This is why
> I wanted glibc involved in this discussion before this arrives to a
> Linux release.  Thanks for the quick feedback!

It's in the Rationale for System Interfaces:

“
[EFTYPE]
    This error code was proposed in earlier proposals as "Inappropriate
    operation for file type", meaning that the operation requested is
    not appropriate for the file specified in the function call. This
    code was proposed, although the same idea was covered by [ENOTTY],
    because the connotations of the name would be misleading. It was
    pointed out that the fcntl() function uses the error code [EINVAL]
    for this notion, and hence all instances of [EFTYPE] were changed to
    this code.
”

I replied on linux-fsdevel, too.

(It would be nice to submit patches introducing new error codes to
linux-api with a subject mentioning the error code.)

Thanks,
Florian

Re: [PATCH v2 1/2] man/man3/errno.3: Document EFTYPE error code

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

Hi Florian,

On 2026-04-27T15:29:30+0200, Florian Weimer wrote:
> * Alejandro Colomar:
> 
> > Hi Florian,
> >
> > On 2026-04-27T12:34:30+0200, Florian Weimer wrote:
> >> * Alejandro Colomar:
> >> 
> >> > [CC += libc-alpha]
> >> >
> >> > Hi Dorjoy,
> >> >
> >> > On 2026-04-26T17:14:25+0600, Dorjoy Chowdhury wrote:
> >> >> Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
> >> >
> >> > Thanks!
> >> >
> >> > 	Reviewed-by: Alejandro Colomar <alx@kernel.org>
> >> >
> >> > I will wait until glibc adds this error code to their <errno.h> before
> >> > applying the patch.  This means either you should write and send a patch
> >> > to glibc (if so, please CC me), or you should ask them to add it
> >> > themselves (if you're not comfortable writing glibc code).
> >> 
> >> I'm not sure where this is coming from.
> >
> > Here's a link to the thread:
> > <https://lore.kernel.org/linux-man/20260426111707.36541-1-dorjoychy111@gmail.com/T/>
> >
> >> POSIX says EFTYPE was rejected
> >> in favor of ENOTTY.
> >
> > Could you please share a link to that?
> >
> > Anyway, I guess ENOTTY would be inappropriate in this case.  Although
> > maybe a better error code could be devised; I don't know.  This is why
> > I wanted glibc involved in this discussion before this arrives to a
> > Linux release.  Thanks for the quick feedback!
> 
> It's in the Rationale for System Interfaces:
> 
> “
> [EFTYPE]
>     This error code was proposed in earlier proposals as "Inappropriate
>     operation for file type", meaning that the operation requested is
>     not appropriate for the file specified in the function call. This
>     code was proposed, although the same idea was covered by [ENOTTY],
>     because the connotations of the name would be misleading. It was
>     pointed out that the fcntl() function uses the error code [EINVAL]
>     for this notion, and hence all instances of [EFTYPE] were changed to
>     this code.
> ”
> 
> I replied on linux-fsdevel, too.

Thanks!

> 
> (It would be nice to submit patches introducing new error codes to
> linux-api with a subject mentioning the error code.)

Thanks!  I'll remember this advice for when receiving patches that add
error codes.

> 
> Thanks,
> Florian

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]