On 9/19/22 08:30, Miklos Szeredi wrote:
On Fri, 16 Sept 2022 at 23:52, Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
On 9/16/22 21:44, Miklos Szeredi wrote:
+static int fuse_tmpfile(struct user_namespace *mnt_userns, struct inode *dir,
+ struct file *file, umode_t mode)
+{
+ struct fuse_conn *fc = get_fuse_conn(dir);
+ int err;
+
+ if (fc->no_tmpfile)
+ goto no_tmpfile;
+
+ err = fuse_create_open(dir, file->f_path.dentry, file, file->f_flags, mode, FUSE_TMPFILE);
+ if (err == -ENOSYS) {
+ fc->no_tmpfile = 1;
+no_tmpfile:
+ err = -EOPNOTSUPP;
+ }
+ return err;
+}
A bit confusing part is that the other file systems are calling your new
finish_tmpfile(), while fuse_create_open() calls finish_open() for
tmpfiles as well. Seems to be identical but won't this easily miss
possible changes done in the future to finish_tmpfile()?
There shouldn't be any such changes. It's really just a shorthand
form of finish_open().
It is just a minor concern for future maintenance, from my point of view
it is better to be entirely consistent.
Would calling it finish_open_simple() help? It really has nothing to
do with tmpfile and .atomic_open instances could call it as well.
Yeah, I think that would be a better name, maybe others could add their
opinion here?
Thanks,
Bernd
