On 10/24/23 12:12, Yuan Yao wrote:
Thank you for addressing the symbolic link problems!
Additionally, I found an incompatibility with the no_open feature.
When the FUSE server has the no_open feature enabled, the atomic_open
FUSE request returns a d_entry with an empty file handler and open
option FOPEN_KEEP_CACHE (for files) or FOPEN_CACHE_DIR (for
directories). With this situation, if we can set fc->no_open = 1 or
fc->no_opendir = 1 after receiving the such FUSE reply, as follows,
will make the atomic_open compatible with no_open feature:
+ if (!inode) {
+ flags &= ~(O_CREAT | O_EXCL | O_TRUNC);
+ fuse_sync_release(NULL, ff, flags);
+ fuse_queue_forget(fm->fc, forget, outentry.nodeid, 1);
+ err = -ENOMEM;
+ goto out_err;
+ }
+
+ if(ff->fh == 0) {
+ if(ff->open_flags & FOPEN_KEEP_CACHE)
+ fc->no_open = 1;
+ if(ff->open_flags & FOPEN_CACHE_DIR)
+ fc->no_opendir = 1;
+ }
+
+ /* prevent racing/parallel lookup on a negative hashed */
Thanks again for your review!
Hmm, are you sure atomic open needs to handle no-open? fuse_file_open
sets no-open / no-opendir on -ENOSYS. _fuse_atomic_open has a handler
for -ENOSYS and falls back to the existing create_open. So why does
atomic open need a no-open handling?
Thanks,
Bernd
