Re: CIFS improvements/wider testing needed

From: Steve French
Date: Mon Nov 21 2005 - 16:29:03 EST


1) save a new openoffice document twice, 2) create mail folders
from inside thunderbird (local mailbox


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.

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)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at