On Friday, March 1, 2002 at 6:00:11 AM UTC+5:30, Hwa-Jin Bae wrote:
NFS servers in Solaris and SunOS always supported appending (as in fopen
with "a"). This is not really done in NFS at all, but in a generic way.
The fopen() is not a system call in Unix; it is a libc routine. Most
fopen() implementations (Solaris, Sunos, netbsd, and vxWorks) will look at the mode string and decode before making a system call open(). If "a" is used, instead of setting O_TRUNC, O_APPEND will be set and sent down to open(). The same behavior is preserved in all Unix machines as well as vxWorks.
vxWorks NFS client (nfsDrv) will pay attention to the mode bits (O_CREAT, O_TRUNC, etc.) and only truncate the file if O_TRUNC is set. It might be useful to call open() instead of fopen() and see what happens. Make sure O_TRUNC is not set and O_APPEND is set.
Regarding the quote BSD kernel code (IO_APPEND flag handling), that is a seperate thing from the higher level thing. fopen() in libraries will call open() and seek to end of file if O_APPEND is set. The semantics of "a" is handled at C library level, not in kernel level. The IO_APPEND is a flag
used as an arg to Vnode ops as per unix style VFS interface within kernel.
It is not related to handling "a" flag of fopen().
Sorry this question still lingers in one head, Do Appends work on NFS(4)?, cause as per the conceptual architecture there is no state on the server which means all clients have a local file size counter and may not work for appends, is this hypothesis
true or i am missing something?
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)