YAMAMOTO Takashi <[email protected]> wrote: > > + rvap->va_size = MAX(rvap->va_size, vp->v_size); > > couldn't it be a problem if the size of the file is shrinked by the server?
In that case, ou client will not see the file being shrunk until it forgets about it and looks it up again. I guess it means that when you hold a file open, you do not see it being shrunk by another client. That may be annoying, though I have trouble to find a situation where it would cause problems. A mail system, perhaps, with clients being SMTP and IMAP daemons? But in such a setup, you use locking so that only a single client opens a mailbox, otherwise you breaak everything. > how about stopping using FAF for SETATTR? > i guess puffs_msg_setcall can be used instead. I am not sure it would fix all corner cases. Basically the problem is that synchronisation of kernel and filesystem view of file size are not atomic. Getting rid of the FAF for SETATTR will not prevent a race with another thread that tests or sets file size. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz [email protected]
