Re: [PATCH][RFT] smbfs bugfixes for 2.4.4

[torvalds@transmeta.com (Linus Torvalds)]

In article <3AF4974C.D5D85498@baldauf.org>,
Xuan Baldauf  <xuan--lkml@baldauf.org> wrote:
>
>it does not fix|work around the bug completely:
>
>1. windows: Create a file, e.g. with 741 bytes.
>2. linux: "ls -la" will show you the file with the correct size (741)
>3. linux: read the file into your smbfs cache (e.g. "less file")
>4. windows: add some contents to the file, e.g. so that it is now 896 bytes
>long
>5. linux: "ls -la" will show you the file with the correct size (896)
>6. linux: read the file (e.g. "less file")
>
>What you should see, on the linux box, are the new contents of the file. What
>you will see are the old contents of the file plus a lot "^@^@^@^@^@^@^@"
>(which mean null bytes) at the end of the old contents.

This is a different problem. Apparently the Linux client does not
invalidate its caches sufficiently often. The smb client should at least
do a "invalidate_inode_pages(inode);" when it notices that the file size
has changed.

It has code to do that in smb_revalidate_inode(), but it may be that
something else refreshes the inode size _without_ doing the proper
invalidation checks. Or maybe Urban broke that logic by mistake while
fixing the other one ;)

		Linus