public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: VALETTE Eric RD-MAPS-REN <eric2.valette@francetelecom.com>
To: Steve French <smfrench@austin.rr.com>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.com
Subject: Re: CIFS improvements/wider testing needed
Date: Tue, 22 Nov 2005 10:19:35 +0100	[thread overview]
Message-ID: <4382E2A7.7080100@francetelecom.com> (raw)
In-Reply-To: <43823BF0.5050408@austin.rr.com>

Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
> 
>>>> 1) save a new openoffice document twice, 2) create mail folders
>>>> from inside thunderbird (local mailbox
>>>>     
>>>
>>> shared
>>>   
>>>
>>>> with windows),
>>>>     
>>>
>>> You can avoid these by mounting with "nobrl" (no remote byte range
>>> lock) mount option (smbfs does not send byte range locks so would not
>>> run into this problem, but would run into others). These appear to be
>>> byte range locking problems. The problem is that cifs has to map
>>> advisory to mandatory locks which only works if the application is
>>> reasonably well behaved (not even Samba has support for advisory
>>> locks although they will come with the new Unix extensions). It may
>>> be made worse by a bug in openoffice (some Linux apps such as
>>> Evolution lock on the "wrong" file handle which does not fail in
>>> posix, although is sloppy coding) but I have not confirmed the byte
>>> range lock sequence which openoffice is trying as we did with
>>> Evolution - I did confirm that nobrl (disabling the byte range locks
>>> on the client) works. Note that this mount option, although not
>>> listed as a bug fix in git per-se - was added to address the
>>> evolution etc. locking bugs. There are quite a few of the cifs
>>> changes that fall into that category.
>>>   
>>
>>
>> Well I would be surprised the "cat >> titi" command does any of this
>> byte range lock. If the "create and later rewrite the same file"
>> sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>> titi), how can it works with complicated applications?
>>
>>  
>>
> The "cat >> titi" failure has nothing to do with the Evolution and
> OpenOffice issues.  We have had multiple people reproduce the strange
> Evolution behavior that was causing problems (months ago) and those can
> be handled now.    Those applications do byte range locking in
> counter-intuitive ways that are hard to map onto the network (and also
> Evolution IIRC also uses "illegal" (to CIFS, but legal to POSIX)
> characters in file names - which we also had to add a mount option for -
> in order to allow remapping of those characters).   The cat failure that
> you describe is likely due to 1) either the need for a full emulation of
> Unix mode bits to Windows ACLs when umask is set to certain values or 2)
> a strange combination of share permissions and ntfs acls on the server
> side which allow create in the directory but not append on new file
> objects.

I'm affraid the OpenOffice issue is indeed caused by the same EACESS
unless you prove me I'm wrong. Usually to create a presentation, I open
an existing one (via CIFS), save it to a new name (on the server via
CIFS) to avoid corrupting the old one (create a file), then modyfy it,
then try to write it (do not manage to modify it). I made the "cat bug"
just to strip the problem to the bare minimum.

> 
>> Yes : the system hangs when shutting down as the result of the "umount
>> -a"  with the last message being as described in bug N° 3237. I have to
>> press power button for 5 seconds.
>>
>> NB : manually doing the umount does exactly the same things.
>>
>>  
>>
> This looks like a corrupt server frame - I will try to get change samba
> to force such an illegal frame to test the changes, but it looks like
> something we can work around with defensive code in the cifs client:
>    1) by allowing a minimum sized response to have an illegal bcc (byte
> area count) under this circumstance
>    2) by making sure SMBLogoffX times out faster (since it is harmless
> to do that in most cases - it is often followed by a tcp session close
> which will implicitly do what SMBLogoffX does anyway)

This makes me *really* wonder how you test your CIFS implementation.  I
would bet you use a Linux server with samba and not real Windows servers
like Windows 2000 server or Windows 2003 server. I can perfectly
understand that for development purpose because you can tarce the both
side, then for validation I think using WindoWS NT (Ok Obsolete but
still), Windows 2000 server or Windows 2003 server is mandatory.


-- eric

  reply	other threads:[~2005-11-22  9:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-21 16:04 CIFS improvements/wider testing needed Steve French
2005-11-21 17:26 ` VALETTE Eric RD-MAPS-REN
2005-11-21 21:28   ` Steve French
2005-11-22  9:19     ` VALETTE Eric RD-MAPS-REN [this message]
     [not found]       ` <43834052.4090509@austin.rr.com>
2005-11-22 16:47         ` VALETTE Eric RD-MAPS-REN
2005-11-21 21:31   ` Steve French
2005-11-22 10:36     ` VALETTE Eric RD-MAPS-REN
2005-11-22 13:57     ` VALETTE Eric RD-MAPS-REN
2005-11-22 16:30       ` CIFS emulated mode bits Steve French
2005-11-22 17:17         ` VALETTE Eric RD-MAPS-REN
     [not found]       ` <43834994.10006@austin.rr.com>
2005-11-22 17:24         ` CIFS improvements/wider testing needed VALETTE Eric RD-MAPS-REN
  -- strict thread matches above, loose matches on Subject: below --
2005-11-22 16:40 Steve French
2005-11-21 13:02 VALETTE Eric RD-MAPS-REN

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=4382E2A7.7080100@francetelecom.com \
    --to=eric2.valette@francetelecom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@austin.rr.com \
    --cc=torvalds@osdl.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