Urban Widmark wrote:
> Hello all
>
> This patch have been building up for a while, without reaching some
> undefined level of readiness. I would like some feedback from other smbfs
> users before submitting this for 2.4.4-something. Particularly from people
> mounting win9x shares.
>
> * win9x will sometimes not give back the right filesize, this can cause
> problems when cp'ing a file over an existing one. When truncating the
> file to 0 bytes the server keeps reporting the old size and much
> confusion arises.
> (reported by Xuan Baldauf, could you verify that this fixes it? If it
> does it's a much better fix than the workaround you got before.)
Hello Urban,
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.
The file sizes used here should be arbitrary, but this concrete case just
happened now. They do not need to have to cross a 512-byte-block boundary or
so.
Also, "ls" is correct every time, only the content is incorrect.
So maybe, if reader and writer are the same smbfs, the bug might be fixed, but
if the writer is another machine than the reader, it is not.
Xuân.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:22 EST