(Lucio posted while I've been thinking/composing/trying things...)
Thanks for putting up with me!
I confess I've been thinking about this a bit more, as something about this doesn't feel right:
As I understand it, the kernel is getting an error string from some file server, and is decorating it with a filename/pathname for the benefit of the user, then returning it to userspace through errstr(2).
exportfs(4) is then sending the decorated error string out to whatever mounts it.
But, another machine that mounts that exported file system will then decorate it a second time... If that composite file system is exported to a third computer, then that system will mount it and its kernel will decorate it a third time...
This being plan 9, you can do this all on the same machine, so I tried it.
In each window I typed/snarfed/pasted something like:
term% srv tcp!themachine!9123 step1
term% mount /srv/step1 /power
term% aux/listen1 -t tcp!*!9124 /bin/service/tcp5564
(/power is just a handy unused directory to mount on. ;))
/bin/service/tcp5564 above is:
#!/bin/rc
exec /bin/exportfs -r /
I created 3 windows, each mounting a composite file system exported from the previous one (by advancing the port numbers and srv names I used above). And sure enough, the error message strings get longer and longer!
Eventually I got:
term% echo >/lib
/fd/0:10: > can't create: lib: is a directory: './power/lib': './power/power/lib': './power/power/power/lib': 'lib'
I had to generate an 'is a directory' error to see this, rather than a 'file not found' error, as the latter seems to get treated a bit differently, and doesn't show this concatenative effect.
This seems a bit daft.
I was thinking that maybe exportfs should be stripping off the filename decoration after all: I'm not sure I can think of a scenario where sending it through Rerror is helpful.
but this still doesn't feel right.
exportfs is having to remove a decoration on an error string that the kernel added for the benefit of the user. I think the kernel should probably not be doing this. The outcome is nice, but maybe it would be better if it were done in libc, perhaps in the implementation of %r. Maybe the system call functions in user space could record the pathname in a global buffer when an error occurs, and %r could use that.
Exportfs could then forward the error string without the kernel decorating it, and we could leave Linux v9fs alone.
Would that be better?
Although English is my first language, I live among people for whom it mostly isn't, so I see these issues every day. There's definitely a tension between the obvious practicality of using English as a "Lingua Franca" and not wanting to lose other languages, which is important to some people. The whole internationalisation thing is complicated and political, and thus hopefully something we can ignore here most of the time! I probably shouldn't have mentioned it. :D