This is what NFS has been doing, for several decades, and no one
has complained yet. It is just generally accepted. I do agree
that it isn't the best of semantics, but it does seem to work and
does solve a real problem which exists if you don't allow an
operation to be interrupted. The alternative, for NFS clients,
was potentially to block an application until a server, which
might never come back up, comes back up. It was a serious
problem and worse than this resolution.
Yes, I'd like to hear the details and find out why it was a
problem. If you allow the fuse file system to block waiting
on things which may never occur, than you are going to have a
problem. I would suggest considering this now instead of waiting
until it is too late. We can learn from the NFS experience instead
of just dismissing it.
Well, you brought it up. I thought that perhaps you had something
other than FUD.
Potential backwards compatibility problems and none are even known
or even considered.
The solution here isn't to create more hacks and a new error number
for this purpose is just a hack.
Please describe this real and existing fuse installation so that I can
better understand the situation and the real requirements here.
Instead of attempting to block this proposal, what about considering
how to architect fuse to handle the situation instead of pretending
that fuse won't have the same problem to solve if it isn't solved
here? I have a real problem to solve and I need to get it resolved.
I have real customers, with real problems, and not just theoretical
and vague ones.
ps
--
