Re: CIFS improvements/wider testing needed

Re: CIFS improvements/wider testing needed

[Steve French]

Eric,
Thanks for the feedback - any bugs which you report which I can 
reproduce - I will treat
as a very high priority and your testing is helpful.

 > Trying to push Linux in corporate environments in such condition is very
 > difficult because, due to those bugs, you cannot:
 >
 >       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.

 >         3) avoid to do FSCK after each reboot,
Not sure that cifs would cause this unless you mean that cifs was hung 
and shutdown hung.   To
avoid cases where cifs requests could stay blocked forever (especially 
locking requests),
I added a umount_begin routine a few weeks ago to try to free threads 
blocked in cifs -
but what I need from users/tests if they see a cifs umount fail is to 
know where the requests
are hung so I can add wakeup calls for that condition in
cifs's umount_begin (you can do "echo t > /proc/sysrq-trigger" then 
"dmesg > debugdata" to get
the debugdata which has the callstacks of processes blocked in kernel).

 > I've seen many changes going in CIFS git tree during this period but
 > only few bugs got really hunted and fixed
Scanning the bugzilla list I don't see many which are still believed to 
be valid, but
the bugzilla list for cifs on bugzilla.samba.org needs to be cleaned up.

 >SMBfs do not exibit some of the bugs CIFS has but has other limitations
SMBfs runs far fewer posix applications.   The main advantage smbfs
has is in its kerberos support (which is being worked with the new cifs
upcall) and in that it cheats and opens multiply open files only once and
with the wrong flags (which can help performance in some cases
but the lack of safe caching can lead to data corruption).

 >Could other on the LKML list try to reproduce/confirm the following bugs
 >with the latest snapshot:
That would be very helpful.

 > NB : the second bug appeared with CIFS 1.39 and is not present in 
2.6.14.2
 >
The smb length checking code was fixed in cifs 1.38 or cifs 1.39 (it was 
missing some
illegal cases where tcp length of the smb did not match the calculated 
smb length of
the three parts of the smb).   It of course could be a security exposure to
overly relax the length checking code on incoming
network buffers.  Unfortunately Windows server has at least one bug in which
its server miscalculates the size of an smb with no data area but an
illegal pad but the empty bcc (byte data) area of an SMB - this can 
occur on
byte range locks but we may be seeing a second case in your example. 

 > BUGS :
 >         <https://bugzilla.samba.org/show_bug.cgi?id=2673>
I suspect that this is a difference in default ACLs or share permissions 
on the windows server side, but
as I have mentioned additinal data would be helpful as no one else so 
far has been able to reproduce it
as far as I know.   If that is not the cause it may be a problem with 
the emulation of Linux mode
bits - and of course some three or four of the most recent cifs changes 
have been working case by
case through improving this to Windows servers.  It is not easy code to 
discover and write.

 >         <https://bugzilla.samba.org/show_bug.cgi?id=3237>
I would like to see the debug data ("cat /proc/fs/cifs/DebugData") so I 
can see if there any
pending network requests when your shutdown occurs - and I want to see 
an ethereal trace
(or tcpdump or equivalent binary trace file) of this so I can see what 
is going on with this
malformed response from the server.

 > May I suggest to fix bugs as a priority before adding new features for a
If there is a known bug, reported and which I can recreate - it is of 
course my highest priority
and I would also evaluate patches to fix such as my highest priority - 
but if they are hard
or impossible for me to recreate - getting the very, very, very hot 
issue of Kerberos security
enablement finished is the priority now.

 > Or at least make sure enough testing is done to avoid regressions?
There is a large test suite of the typical Linux fs tests (connectathon 
posix file api,
fsx, fsstress, dbench, etc.) which is run against Samba and Windows on 
every
update of cifs (by me and Shaggy and others who can help from time to time).
I would love additional testing in the user community especially on a 
broader set of servers
than I can test - one person can't possibly have enough servers to test 
every one of the
variations of  Windows servers or even Samba/unix platform variants - 
and there
are dozens of other nas appliances and cifs servers.
 
Although I would like to find a workaround so it does not hang the 
umount or fail umount
I am not convinced that this is a typical regression - if a server sends 
an illegal response which
we were not catching before ... it would be dangerous to call preventing 
that potential
security problem a regression.

Re: CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:
> Eric,
> Thanks for the feedback - any bugs which you report which I can
> reproduce - I will treat
> as a very high priority and your testing is helpful.

I know you have tried to reproduce them and failed. The question was how
to go further?

>> Trying to push Linux in corporate environments in such condition is
>> very difficult because, due to those bugs, you cannot:
>> 
>> 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?


> 
>> 3) avoid to do FSCK after each reboot,
> Not sure that cifs would cause this unless you mean that cifs was
> hung and shutdown hung. 

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.

> To avoid cases where cifs requests could stay
> blocked forever (especially locking requests), I added a umount_begin
> routine a few weeks ago to try to free threads blocked in cifs - but
> what I need from users/tests if they see a cifs umount fail is to 
> know where the requests are hung so I can add wakeup calls for that
> condition in cifs's umount_begin (you can do "echo t >
> /proc/sysrq-trigger" then "dmesg > debugdata" to get the debugdata
> which has the callstacks of processes blocked in kernel).

Will do that in the bug data.

>> <https://bugzilla.samba.org/show_bug.cgi?id=3237>

> Although I would like to find a workaround so it does not hang the 
> umount or fail umount I am not convinced that this is a typical
> regression - if a server sends an illegal response which we were not
> catching before ... it would be dangerous to call preventing that
> potential security problem a regression.

Hanging a system systematically leading to FSCK on each reboot is not
particularly helpfull given the fact that it happens whebn you are doing
a shutdown in most cases.


-- eric

Re: CIFS improvements/wider testing needed

[Steve French]

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.

>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)

Re: CIFS improvements/wider testing needed

[Steve French]

VALETTE Eric RD-MAPS-REN wrote:

>Steve French wrote:
>  
>
>>Eric,
>>    
>>
>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?
>
>  
>
Make sure that you let me know if your cat example works when mounted 
with the relatively new "noperm" mount option on the client.   At least 
then we will know whether we are looking at a problem with access 
control on the server (ntfs acls) or client (unix mode bits and the 
.permission entry point)

Re: CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

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

Re: CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
> 
>> Steve French wrote:
>>  
>>
>>> Eric,
>>>   
>>
>> 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?
>>
>>  
>>
> Make sure that you let me know if your cat example works when mounted
> with the relatively new "noperm" mount option on the client.   At least
> then we will know whether we are looking at a problem with access
> control on the server (ntfs acls) or client (unix mode bits and the
> .permission entry point)

The simple "cat > titi ..^D ; cat >> titi" case works when mounted with
the noperm option.

BTW : the fstab content is now :

\\r-canaris\ceva6380    /network/home cifs
domain=FTRD,noperm,credentials=/home/ceva6380/.s
ambaShareId 0 0

and the .sambaShareId contains my windows domain (FTRD) login id (same
as $USER value BTW) and the associated password and "umask" at shell
prompts return 0022.

Hope this helps.

--eric

Re: CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
> 
>> Steve French wrote:
>>  
>>
>>> Eric,
>>>   
>>
>> 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?
>>
>>  
>>
> Make sure that you let me know if your cat example works when mounted
> with the relatively new "noperm" mount option on the client.   At least
> then we will know whether we are looking at a problem with access
> control on the server (ntfs acls) or client (unix mode bits and the
> .permission entry point)

Works with the "noperm" mount option.

--eric

CIFS emulated mode bits

[Steve French]

VALETTE Eric RD-MAPS-REN wrote:

>Steve French wrote:
>  
>
>>VALETTE Eric RD-MAPS-REN wrote:
>>
>>    
>>
>>>Steve French wrote:
>>>      
>>>
>>let me know if your cat example works when mounted
>>with the relatively new "noperm" mount option on the client.   At least
>>then we will know whether we are looking at a problem with access
>>control on the server (ntfs acls) or client (unix mode bits and the
>>.permission entry point)
>>    
>>
>
>Works with the "noperm" mount option.
>
>--eric
>
>  
>
OK - That is good, should be relatively easy to debug from here.

To explain what is going on, here is some obvious background.    Windows 
uses a rich ACL model locally and over the network via CIFS (other 
protocols such as NFSv4 now do something similar) and Windows of course 
does not have really have or need Unix mode bits ... and the server 
(unlike Samba and those that implement the standard SNIA CIFS Unix 
extensions) does not return emulated mode bits (although it does locally 
in Windows "services for Unix" and of course also cygwin does something 
similar) ... so the cifs  client has to approximate mode bits.    If the 
client makes an incorrect approximation you can get access denied on a 
client side permission check.   Of course some would argue that for 
clients that are running as single user desktop clients the client does 
not need to do perm checks (the server does ACL checks) so just turn off 
the client permission checks - that is why the "noperm" option is 
available on the cifs client.

So the choices today are:

1) Turn off mode bit checking (on the client) on a particular cifs mount 
(noperm mount option)
or
2) pass in a default mode and uid or gid on the cifs mount that matches 
what you want (otherwise cifs will use the uid of the mounter, and a 
default mode).  Although cifs caches the mode bits in the inode if they 
are modified by an app on the client e.g. via chmod (while the inode 
stays in memory on the client) - for querying (lookups/stat) on existing 
files cifs can only use the +R dos attribute to distinguish when to 
return something other than 0777 (or the default).
or
3) turn on the "sfu" mount option on the client and let cifs make the 
(more expensive) queries to the server for mode information the same way 
that "services for unix" would.   This does not work for all mode bits 
yet, as it requires additional CIFS ACL support to be coded, but it does 
now work for the 3 bits above 0777 (as of just after 2.6.15-rc2).

Following the suggestions of Martin Koeppe and others there may be a 
need to allow a "cygwin" mount option as well.

Re: CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:

>>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.

> There are two big test events for CIFS each year (Connectathon and the
> SNIA CIFS conference) in which all of the major CIFS vendors servers and
> clients (including the Linux cifs client) are tested together.   These
> two events has been the most helpful for me every year as they are for
> many others on the Samba team (lots of Samba server progress also
> happens in these two weeks).   That is the best opportunity (almost the
> only good opportunity) for testing against EMC, NetApp, Adaptec/SNAP,
> AIX FastConnect, and the other NAS vendors - and at each event a few
> client bugs have been fixed or client workarounds for server bugs have
> been added as a result of this testing.   For weekly testing there are
> of course more test environments than mine, and I get feedback from
> those testing against other server versions, but I have a small test
> environment at home and also one at work (there are other unrelated test
> groups that test the version of cifs and Samba before distro releases)
> that I regularly test against.  It would be impossible for one person to
> test against the breadth of servers out there so community testing,
> especially against the less well known servers, is encouraged.  

That is great that such "plug fest" exists and I agree with you that
this is the only way to test compatibility to such scale.

> In my test environment these are tested almost daily as target servers:
> 
> 1) Samba version 3 (current)
> 2) Windows XP service pack 2


Do you have collected any statistics on Windows server market share per
windows version? I would bet 2000 Server is still mainstream with 2003
slowly replacing NT4 in term of percentage now that support is stopped.

Idealy, may I suggest that dayly testing platforms, should match this
real life Winddows server platform distribution.


-- eric

Re: CIFS emulated mode bits

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:

> To explain what is going on, here is some obvious background.    Windows
> uses a rich ACL model locally and over the network via CIFS (other
> protocols such as NFSv4 now do something similar) and Windows of course
> does not have really have or need Unix mode bits ... and the server
> (unlike Samba and those that implement the standard SNIA CIFS Unix
> extensions) does not return emulated mode bits (although it does locally
> in Windows "services for Unix" and of course also cygwin does something
> similar) ... so the cifs  client has to approximate mode bits.    If the
> client makes an incorrect approximation you can get access denied on a
> client side permission check.   Of course some would argue that for
> clients that are running as single user desktop clients the client does
> not need to do perm checks (the server does ACL checks) so just turn off
> the client permission checks - that is why the "noperm" option is
> available on the cifs client.
> 
> So the choices today are:
> 
> 1) Turn off mode bit checking (on the client) on a particular cifs mount
> (noperm mount option)

I could live with that altthough there is something I would like to
clarify (see below).

> or
> 2) pass in a default mode and uid or gid on the cifs mount that matches
> what you want (otherwise cifs will use the uid of the mounter, and a
> default mode).  Although cifs caches the mode bits in the inode if they
> are modified by an app on the client e.g. via chmod (while the inode
> stays in memory on the client) - for querying (lookups/stat) on existing
> files cifs can only use the +R dos attribute to distinguish when to
> return something other than 0777 (or the default).

If you put something is a /etc/fstab, that will be mounted by init
scripts, the uid/gid credentials attached with the mount request is of
course root.root (which is wht is see with "ls file" BTW). 'I'm just
surprised that with the perm option, my identity seems to change, on the
client side, between the two commands : if the file is marked locally as
created by root.root, I should still be root.root for the next command!

Side question for my understanding : when I specify  the credentials
(like I did) (credentials=/home/ceva6380/.sambaShareId) and that the
user name exist in the local /etc/passwd, I'm surprised to have to add
the uid=getuidfrom(name) again. I admit, user name on the windows server
may be different than on the client, but to put a valid uid/gid it must
exist on the client system anyway and be consistent with the current
user identity no?


-- eric

Re: CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
> 
>>Steve French wrote:
>>  
>>
>>>VALETTE Eric RD-MAPS-REN wrote:
>>>
>>>    
>>>
>>>>Steve French wrote:
>>>> 
>>>>
>>>>      
>>>>
>>>>>Eric,
>>>>>  
>>>>>        
>>>>>
>>>>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?
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>Make sure that you let me know if your cat example works when mounted
>>>with the relatively new "noperm" mount option on the client.   At least
>>>then we will know whether we are looking at a problem with access
>>>control on the server (ntfs acls) or client (unix mode bits and the
>>>.permission entry point)
>>>    
>>>
>>
>>Works with the "noperm" mount option.
>>
>>--eric
>>
>>  
>>
> Could you run "stat titi" and/or "ls -l titi" between the
>     "cat > titi"
> and the
>     "cat >> titi"

cat > toto
toto
8 r-ptxp-ceva6380:/network/home/test3->ls -l toto
-rw-r--r-- 1 root root 5 2005-11-22 17:50 toto
9 r-ptxp-ceva6380:/network/home/test3->cat >>titi
tata
10 r-ptxp-ceva6380:/network/home/test3->ls -l toto
-rw-r--r-- 1 root root 5 2005-11-22 17:50 toto

OK, I'm not root.root but why does my identity seem to change between
the file creation and the file rewrite?

-- eric

Re: CIFS improvements/wider testing needed

[Steve French]

VALETTE Eric RD-MAPS-REN wrote:

>Steve French wrote:
>  
>
>>VALETTE Eric RD-MAPS-REN wrote:
>>
>>    
>>
>>>Steve French wrote:
>>> 
>>>
>>>      
>>>
>>>>Eric,
>>>>  
>>>>        
>>>>
>>>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?
>>>
>>> 
>>>
>>>      
>>>
>>Make sure that you let me know if your cat example works when mounted
>>with the relatively new "noperm" mount option on the client.   At least
>>then we will know whether we are looking at a problem with access
>>control on the server (ntfs acls) or client (unix mode bits and the
>>.permission entry point)
>>    
>>
>
>Works with the "noperm" mount option.
>
>--eric
>
>  
>
Could you run "stat titi" and/or "ls -l titi" between the
    "cat > titi"
and the
    "cat >> titi"

so I can see what cifs thinks the owner of the file is and the mode.   I 
also need to know the current user so I can see whether it matches what 
cifs has as the owner of the file.    Note that readdir (ls of a 
directory or ls with a wildcard) and lookup (ls of a specific file, or 
stat) hit different code paths in the cifs vfs but both cause default 
mode bits to be put in the inode metadata.

If this does not point out the problem, then I will give you a modified 
version of cifs_permission to trace what is happening.

CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

As probably many others, I work in an environment where Windows servers
 (and thus CIFS filesystem) is used to store home data and backuped
shared data. With OpenOffice 2.0 now out, reading and writing Microsoft
Office documents is generally not anymore a problem except due to
current CIFS bugs.

I tried to do my part of bug hunting, carefully reporting bugs and
offering help to try to fix them (although I cannot do too hazardous
testing on my professional Laptop. See bugzilla reference below).
Unfortunately, things did not improve over the past 5 months and even
recently slightly got worse (see second bug).

Trying to push Linux in corporate environments in such condition is very
difficult because, due to those bugs, you cannot:

	1) save a new openoffice document twice,
	2) create mail folders from inside thunderbird (local mailbox shared
with windows),
	3) avoid to do FSCK after each reboot,

I've seen many changes going in CIFS git tree during this period but
only few bugs got really hunted and fixed (try to set the close option
in bugzilla at
<https://bugzilla.samba.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=CifsVFS&content=>).
SMBfs do not exibit some of the bugs CIFS has but has other limitations
as well.

Could other on the LKML list try to reproduce/confirm the following bugs
with the latest snapshot:

NB : the second bug appeared with CIFS 1.39 and is not present in 2.6.14.2

BUGS :
	<https://bugzilla.samba.org/show_bug.cgi?id=2673>
	<https://bugzilla.samba.org/show_bug.cgi?id=3237>


May I suggest to fix bugs as a priority before adding new features for a
while? Or at least make sure enough testing is done to avoid regressions?



-- eric