public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Xuan Baldauf <xuan--lkml@baldauf.org>
To: Urban Widmark <urban@teststation.com>
Cc: linux-kernel@vger.kernel.org, Xuan Baldauf <xuan--lkml@baldauf.org>
Subject: Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
Date: Sun, 06 May 2001 02:14:04 +0200	[thread overview]
Message-ID: <3AF4974C.D5D85498@baldauf.org> (raw)
In-Reply-To: <Pine.LNX.4.30.0103162326530.28939-200000@cola.teststation.com>



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.



  reply	other threads:[~2001-05-06  0:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-02 21:59 [PATCH][RFT] smbfs bugfixes for 2.4.4 Urban Widmark
2001-05-06  0:14 ` Xuan Baldauf [this message]
2001-05-06 10:16   ` Urban Widmark
2001-05-07 17:44   ` Linus Torvalds
2001-05-08 20:43     ` Urban Widmark
2001-05-08 22:02       ` James H. Puttick
2001-05-21 11:00       ` Xuan Baldauf
2001-05-21 18:03         ` Urban Widmark
2001-05-22 22:25         ` Urban Widmark
2001-05-22 22:57           ` Xuan Baldauf
2001-05-22 23:12             ` Urban Widmark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3AF4974C.D5D85498@baldauf.org \
    --to=xuan--lkml@baldauf.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=urban@teststation.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox