On 5/22/19 4:22 PM, Alan Somers wrote: > On Wed, May 22, 2019 at 5:18 PM Johannes Lundberg <johalun_at_freebsd.org> wrote: >> >> On 5/22/19 4:12 PM, Johannes Lundberg wrote: >>> On 5/22/19 3:02 PM, Conrad Meyer wrote: >>>> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg <johalun_at_freebsd.org> wrote: >>>>>> It seems, a single '>' will cause it to try to create the file (even >>>>>> though it already exists) and that fails (kern_openat). >>>>>> >>>>> I would guess because of >>>>> >>>>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042 >>>>> >>>>> struct vop_vector pfs_vnodeops = { >>>>> ... >>>>> .vop_create = VOP_EOPNOTSUPP, >>>>> ... >>>>> } >>>> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei() >>>> cannot find the named vnode (ni_vp == NULL). Otherwise, it should >>>> just invoke VOP_OPEN. This suggests there might be a lookup bug in >>>> pfs? Tracing VOPs as Mark suggested seems like a good next step. >>>> >>>> Best, >>>> Conrad >>> Thanks Conrad. Yeah, that makes sense that it would open instead of >>> recreating. Tracing a'la Mark points to >>> >>> vop_getwritemount >>> >>> failing. >> Actually vop_setattr also shows up in dtrace. >> >> I'll continue digging.. > vop_setattr would get called to truncate the file's size down to 0. > That's probably called by sh which is opening the file with O_TRUNC. > > -Alan It works if I simply return 0 from pfs_setattr so that's the culprit indeed. Hmm, wonder if there's any elegant solution to this..Received on Wed May 22 2019 - 21:33:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC