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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.