-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create unnamed O_TMPFILE fails in VirtFS (error 22(EINVAL): Invalid argument
)
#2051
Comments
Creation of unnamed temporary files in a 9P filesystem is indeed not supported. |
@francescolavra thanks for the answer! As far as I see from Linux man, In that case, probably it is possible to change the error code? From that man page (ERRORS section) I can see these three codes which are treated as "O_TMPFILE files are not supported on the filesystem":
Some libraries which work with temp files check for these error codes to decide if they need to fallback to normal named files. So it would be very helpful, if nanos |
To be clear, when I said that creation of unnamed temporary files is not supported on Linux, I meant that it's not supported in a 9P filesystem, i.e. a filesystem mounted with the |
Having filesystem-specific error codes requires conversion between filesystem codes and POSIX standard codes every time a filesystem- related error is reported to userspace. For the 9P filesystem, in some cases a double conversion (from a standard code to a filesystem code and then back to a standard code) may need to be done. This change removes the fs_status enum that declares the filesystem error codes, and uses standard POSIX codes to report filesystem errors; this allows eliminating the above conversions. Standard error codes are defined in the new kernel/errno.h header file; in order to prevent this file from being included from userspace code, the kernel directory is being removed from the include paths in the relevant Makefiles; this required some adjustments to other header files so that they can be included by both kernel and non- kernel code. For the 9P filesystem, the p9_create() callback function is being modified so that EOPNOTSUPP is returned instead or EINVAL if the user program tries to open a file with the O_TMPFILE flag (#2051).
Having filesystem-specific error codes requires conversion between filesystem codes and POSIX standard codes every time a filesystem- related error is reported to userspace. For the 9P filesystem, in some cases a double conversion (from a standard code to a filesystem code and then back to a standard code) may need to be done. This change removes the fs_status enum that declares the filesystem error codes, and uses standard POSIX codes to report filesystem errors; this allows eliminating the above conversions. Standard error codes are defined in the new kernel/errno.h header file; in order to prevent this file from being included from userspace code, the kernel directory is being removed from the include paths in the relevant Makefiles; this required some adjustments to other header files so that they can be included by both kernel and non- kernel code. For the 9P filesystem, the p9_create() callback function is being modified so that EOPNOTSUPP is returned instead or EINVAL if the user program tries to open a file with the O_TMPFILE flag (#2051).
Having filesystem-specific error codes requires conversion between filesystem codes and POSIX standard codes every time a filesystem- related error is reported to userspace. For the 9P filesystem, in some cases a double conversion (from a standard code to a filesystem code and then back to a standard code) may need to be done. This change removes the fs_status enum that declares the filesystem error codes, and uses standard POSIX codes to report filesystem errors; this allows eliminating the above conversions. Standard error codes are defined in the new kernel/errno.h header file; in order to prevent this file from being included from userspace code, the kernel directory is being removed from the include paths in the relevant Makefiles; this required some adjustments to other header files so that they can be included by both kernel and non- kernel code. For the 9P filesystem, the p9_create() callback function is being modified so that EOPNOTSUPP is returned instead or EINVAL if the user program tries to open a file with the O_TMPFILE flag (#2051).
As part of a larger refactoring, #2054 changes the error code returned by open(O_TMPFILE) from EINVAL to EOPNOTSUPP. |
Having filesystem-specific error codes requires conversion between filesystem codes and POSIX standard codes every time a filesystem- related error is reported to userspace. For the 9P filesystem, in some cases a double conversion (from a standard code to a filesystem code and then back to a standard code) may need to be done. This change removes the fs_status enum that declares the filesystem error codes, and uses standard POSIX codes to report filesystem errors; this allows eliminating the above conversions. Standard error codes are defined in the new kernel/errno.h header file; in order to prevent this file from being included from userspace code, the kernel directory is being removed from the include paths in the relevant Makefiles; this required some adjustments to other header files so that they can be included by both kernel and non- kernel code. For the 9P filesystem, the p9_create() callback function is being modified so that EOPNOTSUPP is returned instead or EINVAL if the user program tries to open a file with the O_TMPFILE flag (#2051).
Description
When I'm trying to create unnamed temporary file
O_TMPFILE
in directory mounted with VirtFS, it fails witherror 22: invalid argument
.Reproduce
Consider following C code :
main.c
:Compile code and run with
ops
, mounting directory through VirtFS:Expected result
Program works successfully, just like on native Linux platform: unnamed tmp file is created and removed at the end of execution. Printed
fd
is positive:Actual result
Returned
fd
is-1
:Setup
I tested the same with --nightly and with local build of master branch and the same error occurs.
What I found
It looks like to me that
open()
syscall results in callingfilesystem_creat_unnamed
function, and 9pfs implementation fails immediately if asked to create unnamed file.But I'm not sure, if 9pfs supports unnamed files at all. In that case this behavior is different from Unix-like, where creating such unnamed tmp files is a normal thing.
The text was updated successfully, but these errors were encountered: