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
next prev parent 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