Date: Thu, 25 Mar 2021 06:27:50 +0000 From: bugzilla-noreply@freebsd.org To: gnome@FreeBSD.org Subject: [Bug 254452] [fusefs] [devel/gvfs]: gvfsd-fuse needs FUSE_CAP_ATOMIC_O_TRUNC from fuse Message-ID: <bug-254452-6497-tCLPBvLb2l@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-254452-6497@https.bugs.freebsd.org/bugzilla/> References: <bug-254452-6497@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254452 --- Comment #5 from Damjan Jovanovic <damjan.jov@gmail.com> --- (In reply to Alan Somers from comment #4) Thank you for the detailed explanation :) While Linux's design is questionable ("each file system is responsible for managing every file's seek offset" :-D), that is the better option for a networked file system, so the remote end knows that it's O_APPENDing and pa= sses O_APPEND to its kernel and does the right thing when multiple clients are writing through it. I was thinking we make that behavior selectable, eg. a = new API fuse.ko can use to opt-in to take over appending and truncating, while existing filesystems continue as they are. Ok so caching needs changes already... This VFS code is in /usr/src/sys/kern/vfs* right? It wasn't pleasant reading when last I looked. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254452-6497-tCLPBvLb2l>