[linux-cifs-client] lseek(x, x, SEEK_END) and the infinite dentry cache

[Maximiliano Curia]

On Tuesday 27 December 2005 14:06, Maximiliano Curia wrote:
> I'm debugging some data-loss problems that I've been having, with old
> clipper applications running inside dosemu.  I work in a mixed-client
> environment with some Windows and some Linux clients.  All the servers run
> Linux.

As a follow up to the previous message, I've been reading more of the
cifs code and I realized that the lseek call returns the wrong value
when the file has been opened in *write mode*.

This is explained in the comment section before the
"is_size_safe_to_change" function (called from inside the revalidate
function, that is used when doing an lseek), in the "inode.c" file:

/* We do not want to update the file size from server for inodes
   open for write - to avoid races with writepage extending
   the file - in the future we could consider allowing
   refreshing the inode only on increases in the file size 
   but this is tricky to do without racing with writebehind
   page caching in the current Linux kernel design */

I understand the reasoning behind this statement, but this doesn't seem
to take into account that multiple stations might have the file open for
writing and the file might have been modified externally.

I'm dealing with all this because I'm experiencing severe data-loss,
because the multiple-client situation is real: multiple stations are
updating the same dbf files, and the Linux stations don't update the
file sizes and therefore overwrite whatever was written by the other
stations.

So, I really need to work around this problem. I guess that I need to
rewrite the "is_size_safe_to_change" function, but I'm not sure what the
best approach to fixing it correctly is.  

Any advice will be appreciated.

-- 
Saludos,
 /\/\ /\ >< `/