Weirdness when writing to pseudofs file

Johannes Lundberg johalun at FreeBSD.org
Wed May 22 20:53:32 UTC 2019


On 5/22/19 11:03 AM, Alan Somers wrote:
> On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg <johalun at freebsd.org> wrote:
>>
>> On 5/22/19 10:51 AM, Konstantin Belousov wrote:
>>> On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
>>>> Hi
>>>>
>>>> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
>>>> to a file,
>>>>
>>>> this works: # echo  1 >> /path/to/file
>>>>
>>>> but this does not: # echo 1 > /path/to/file
>>>>
>>>> "Operation not supported." is returned before the pseudofs code is even
>>>> entered.
>>>>
>>>> Is this expected behavior? (if so, why?)
>>> Does the file exist ?
>>>
>>> Pseudofs does not implement VOP_CREATE(), which is reasonable.
>> Yes, it exists and my custom write function is receiving the call for
>> ">>". (which is for example used by drm driver debugfs to do certain
>> things on demand by accepting write to a debugfs file)
> First, you need to try ktrace to see exactly which system call is not
> supported.  If the problem still isn't obvious, then you can try
> dtrace to see exactly which VOP isn't suppoted.  Do it like this:
>
> sudo ktrace /bin/sh -c "echo 1 > /path/to/file"
> sudo kdump
> sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c
> 'echo 1 > /path/to/file/'"
>
> The dtrace command will show you which function returned EOPNOTSUPP.
> However, it will also show a lot of functions that coincidentally
> return 45 even though it's not an errno, and even functions that
> return void.
>
> -Alan


Thanks!

It seems, a single '>' will cause it to try to create the file (even
though it already exists) and that fails (kern_openat).




More information about the freebsd-current mailing list