[PATCH] cifs: Fix missing braces in fs/cifs/inode.c

[Suresh Jayaraman-2]

It seems commit cea218054ad277d6c126890213afde07b4eb1602 missed a set of
braces. Cleaning up.


Signed-off-by: Suresh Jayaraman<sjayaraman@...>
---

 fs/cifs/inode.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 722be54..764558a 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1310,10 +1310,11 @@ int cifs_revalidate(struct dentry *direntry)
 /* if (S_ISDIR(direntry->d_inode->i_mode))
  shrink_dcache_parent(direntry); */
  if (S_ISREG(direntry->d_inode->i_mode)) {
- if (direntry->d_inode->i_mapping)
+ if (direntry->d_inode->i_mapping) {
  wbrc = filemap_fdatawait(direntry->d_inode->i_mapping);
  if (wbrc)
  CIFS_I(direntry->d_inode)->write_behind_rc = wbrc;
+ }
  /* may eventually have to do this for open files too */
  if (list_empty(&(cifsInode->openFileList))) {
  /* changed on server - flush read ahead pages */

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Fri, 20 Jun 2008 16:33:27 +0530
Suresh Jayaraman <sjayaraman@...> wrote:

> It seems commit cea218054ad277d6c126890213afde07b4eb1602 missed a set of
> braces. Cleaning up.
>
>
> Signed-off-by: Suresh Jayaraman<sjayaraman@...>
> ---
>
>  fs/cifs/inode.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index 722be54..764558a 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -1310,10 +1310,11 @@ int cifs_revalidate(struct dentry *direntry)
>  /* if (S_ISDIR(direntry->d_inode->i_mode))
>   shrink_dcache_parent(direntry); */
>   if (S_ISREG(direntry->d_inode->i_mode)) {
> - if (direntry->d_inode->i_mapping)
> + if (direntry->d_inode->i_mapping) {
>   wbrc = filemap_fdatawait(direntry->d_inode->i_mapping);
>   if (wbrc)
>   CIFS_I(direntry->d_inode)->write_behind_rc = wbrc;
> + }
>   /* may eventually have to do this for open files too */
>   if (list_empty(&(cifsInode->openFileList))) {
>   /* changed on server - flush read ahead pages */
>

Your patch looks good to me. I think the fact that we set wbrc to 0 in
the declaration keeps this from causing a real bug, but the braces
should be there.

Cheers,
--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Günter Kukkukk-2]

I post that here - so it's not going to be forgotten.

Again and again there are posts to many mailing lists,
that cifs vfs is handling timestamps improperly.
Regarding legacy servers, special copy operations just fail.
(the todays smbfs vs. cifs legacy problem)

Test environment:
 - latest git cifs vfs is mounted against
    - winNT
    - WinXP
    - OS/2
    - Win98SE

Unfortunately, this one cannot be simply explained in 3 words ...
----------------------------

To make it as clear as possible - the mount commands:
*****************************************************
WinNT server:
=============
mount -t cifs //wrkgk/test /mnt/winnt -o cred=/root/sec/sec_gk,dir_mode=0775,file_mode=0764,uid=gk,gid=users

WinXP server:
=============
mount -t cifs //cboyer/gk /mnt/winxp -o cred=/root/sec/sec_gk,dir_mode=0775,file_mode=0764,uid=gk,gid=users

OS/2 server:
============
mount -t cifs //server01/CIFS /mnt/server -o cred=/root/sec/sec_gk,sec=lanman,servern=SERVER01,port=139,dir_mode=0775,file_mode=0764,uid=gk,gid=users

Win98SE:
========
mount -t cifs //win98/CIFS /mnt/win9x -o cred=/root/sec/sec_gk,servern=WIN98,dir_mode=0775,file_mode=0764,uid=gk,gid=users

------------------------------------------------------

The results of "cp -p local_file /mnt/some_server":
***************************************************
NOTE:
   cp -p src dst
the '-p' option should preserve time stamps - at least the
last modification time!

WinNT:
======
gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/winnt/ && sleep 1 && stat /mnt/winnt/dummy.tst
  File: `dummy.tst'
  Size: 51078           Blocks: 104        IO Block: 4096   regular file
Device: 306h/774d       Inode: 1054939     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
Access: 2008-07-09 04:32:26.000000000 +0200
Modify: 2007-05-07 21:52:40.000000000 +0200
Change: 2008-07-09 04:32:24.000000000 +0200
  File: `/mnt/winnt/dummy.tst'
  Size: 51078           Blocks: 104        IO Block: 16384  regular file
Device: 10h/16d Inode: 11749       Links: 1
Access: (0764/-rwxrw-r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
Access: 2008-07-09 04:35:06.854217400 +0200   !!!!!!!!!!!!!!!!!!!!!
Modify: 2008-07-09 04:35:06.794122600 +0200   !!!!!!!!!!!!!!!!!!!!!
Change: 2008-07-09 04:35:06.794122600 +0200   !!!!!!!!!!!!!!!!!!!!!

WinXP:
======
gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/winxp/ && sleep 1 && stat /mnt/winxp/dummy.tst
  File: `dummy.tst'
  Size: 51078           Blocks: 104        IO Block: 4096   regular file
Device: 306h/774d       Inode: 1054939     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
Access: 2008-07-09 04:32:24.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
Modify: 2007-05-07 21:52:40.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
Change: 2008-07-09 04:32:24.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
  File: `/mnt/winxp/dummy.tst'
  Size: 51078           Blocks: 104        IO Block: 16384  regular file
Device: 11h/17d Inode: 11484       Links: 1
Access: (0764/-rwxrw-r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
Access: 2008-07-09 04:31:31.012852800 +0200
Modify: 2008-07-09 04:31:31.012852800 +0200
Change: 2008-07-09 04:31:31.012852800 +0200

OS/2:
=====
gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/server/ && sleep 1 && stat /mnt/server/dummy.tst
  File: `dummy.tst'
  Size: 51078           Blocks: 104        IO Block: 4096   regular file
Device: 306h/774d       Inode: 1054939     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
Access: 2008-07-09 04:46:16.000000000 +0200
Modify: 2007-05-07 21:52:40.000000000 +0200
Change: 2008-07-09 04:32:24.000000000 +0200
cp: preserving times for `/mnt/server/dummy.tst': Invalid argument

Win98SE:
========
gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/win9x/ && sleep 1 && stat /mnt/win9x/dummy.tst
  File: `dummy.tst'
  Size: 51078           Blocks: 104        IO Block: 4096   regular file
Device: 306h/774d       Inode: 1054939     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
Access: 2008-07-09 04:36:04.000000000 +0200
Modify: 2007-05-07 21:52:40.000000000 +0200
Change: 2008-07-09 04:32:24.000000000 +0200
cp: preserving times for `/mnt/win9x/dummy.tst': Invalid argument
-----------------------------------------------------------------

Conclusion:
===========
WinNT and WinXP just _silently_ FAIL!
OS/2 and Win98SE just fail with an error msg!

All this is "a known cifs failure" for weeks now - Jeff Layton
has prepared a (large) patch to "cleanup the cifs_setattr()"
stuff - and I'm waiting to post more legacy functionality.

... but nothing happens ...

A really sad situation, when realizing that even the samba
smbfs helpers smbmount, smbmnt and smbumount have now been
removed in 3.2.x.

Cheers, Günter
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Wed, 9 Jul 2008 05:55:34 +0200
Günter Kukkukk <linux@...> wrote:

> I post that here - so it's not going to be forgotten.
>
> Again and again there are posts to many mailing lists,
> that cifs vfs is handling timestamps improperly.
> Regarding legacy servers, special copy operations just fail.
> (the todays smbfs vs. cifs legacy problem)
>
> Test environment:
>  - latest git cifs vfs is mounted against
>     - winNT
>     - WinXP
>     - OS/2
>     - Win98SE
>
> Unfortunately, this one cannot be simply explained in 3 words ...
> ----------------------------
>
> To make it as clear as possible - the mount commands:
> *****************************************************
> WinNT server:
> =============
> mount -t cifs //wrkgk/test /mnt/winnt -o cred=/root/sec/sec_gk,dir_mode=0775,file_mode=0764,uid=gk,gid=users
>
> WinXP server:
> =============
> mount -t cifs //cboyer/gk /mnt/winxp -o cred=/root/sec/sec_gk,dir_mode=0775,file_mode=0764,uid=gk,gid=users
>
> OS/2 server:
> ============
> mount -t cifs //server01/CIFS /mnt/server -o cred=/root/sec/sec_gk,sec=lanman,servern=SERVER01,port=139,dir_mode=0775,file_mode=0764,uid=gk,gid=users
>
> Win98SE:
> ========
> mount -t cifs //win98/CIFS /mnt/win9x -o cred=/root/sec/sec_gk,servern=WIN98,dir_mode=0775,file_mode=0764,uid=gk,gid=users
>
> ------------------------------------------------------
>
> The results of "cp -p local_file /mnt/some_server":
> ***************************************************
> NOTE:
>    cp -p src dst
> the '-p' option should preserve time stamps - at least the
> last modification time!
>
> WinNT:
> ======
> gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/winnt/ && sleep 1 && stat /mnt/winnt/dummy.tst
>   File: `dummy.tst'
>   Size: 51078           Blocks: 104        IO Block: 4096   regular file
> Device: 306h/774d       Inode: 1054939     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
> Access: 2008-07-09 04:32:26.000000000 +0200
> Modify: 2007-05-07 21:52:40.000000000 +0200
> Change: 2008-07-09 04:32:24.000000000 +0200
>   File: `/mnt/winnt/dummy.tst'
>   Size: 51078           Blocks: 104        IO Block: 16384  regular file
> Device: 10h/16d Inode: 11749       Links: 1
> Access: (0764/-rwxrw-r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
> Access: 2008-07-09 04:35:06.854217400 +0200   !!!!!!!!!!!!!!!!!!!!!
> Modify: 2008-07-09 04:35:06.794122600 +0200   !!!!!!!!!!!!!!!!!!!!!
> Change: 2008-07-09 04:35:06.794122600 +0200   !!!!!!!!!!!!!!!!!!!!!
>
> WinXP:
> ======
> gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/winxp/ && sleep 1 && stat /mnt/winxp/dummy.tst
>   File: `dummy.tst'
>   Size: 51078           Blocks: 104        IO Block: 4096   regular file
> Device: 306h/774d       Inode: 1054939     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
> Access: 2008-07-09 04:32:24.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
> Modify: 2007-05-07 21:52:40.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
> Change: 2008-07-09 04:32:24.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
>   File: `/mnt/winxp/dummy.tst'
>   Size: 51078           Blocks: 104        IO Block: 16384  regular file
> Device: 11h/17d Inode: 11484       Links: 1
> Access: (0764/-rwxrw-r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
> Access: 2008-07-09 04:31:31.012852800 +0200
> Modify: 2008-07-09 04:31:31.012852800 +0200
> Change: 2008-07-09 04:31:31.012852800 +0200
>
> OS/2:
> =====
> gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/server/ && sleep 1 && stat /mnt/server/dummy.tst
>   File: `dummy.tst'
>   Size: 51078           Blocks: 104        IO Block: 4096   regular file
> Device: 306h/774d       Inode: 1054939     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
> Access: 2008-07-09 04:46:16.000000000 +0200
> Modify: 2007-05-07 21:52:40.000000000 +0200
> Change: 2008-07-09 04:32:24.000000000 +0200
> cp: preserving times for `/mnt/server/dummy.tst': Invalid argument
>
> Win98SE:
> ========
> gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/win9x/ && sleep 1 && stat /mnt/win9x/dummy.tst
>   File: `dummy.tst'
>   Size: 51078           Blocks: 104        IO Block: 4096   regular file
> Device: 306h/774d       Inode: 1054939     Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
> Access: 2008-07-09 04:36:04.000000000 +0200
> Modify: 2007-05-07 21:52:40.000000000 +0200
> Change: 2008-07-09 04:32:24.000000000 +0200
> cp: preserving times for `/mnt/win9x/dummy.tst': Invalid argument
> -----------------------------------------------------------------
>
> Conclusion:
> ===========
> WinNT and WinXP just _silently_ FAIL!
> OS/2 and Win98SE just fail with an error msg!
>
> All this is "a known cifs failure" for weeks now - Jeff Layton
> has prepared a (large) patch to "cleanup the cifs_setattr()"
> stuff - and I'm waiting to post more legacy functionality.
>
> ... but nothing happens ...
>
> A really sad situation, when realizing that even the samba
> smbfs helpers smbmount, smbmnt and smbumount have now been
> removed in 3.2.x.
>
> Cheers, Günter

Hi Günter,

I think Steve is on holiday this week (it's summer holiday season here
in the US). I think he's waiting for 2.6.26 to be released before
committing more patches. IMO, If you have patches you're just sitting
on, then go ahead and post them and just make it clear that they depend
on other, uncommitted patches. I'm working on some other things too and
I'd like to make sure what I'm doing doesn't conflict with your work
(or anyone else's), and that we're not duplicating each others efforts.

As a side note, it might be nice if Steve had a "devel" branch in his
git tree for stuff intended for the next release so that development
could more easily continue during the mainline -rc phases. Of course, I
need to get to work on a hosted git tree of my own as well ;-)

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Steve French-2]

Starting to catchup now.   I like the idea of having a devel branch
that anyone could push to but not sure the easiest way to handle this.

On Wed, Jul 9, 2008 at 6:02 AM, Jeff Layton <jlayton@...> wrote:

> On Wed, 9 Jul 2008 05:55:34 +0200
> Günter Kukkukk <linux@...> wrote:
>
>> I post that here - so it's not going to be forgotten.
>>
>> Again and again there are posts to many mailing lists,
>> that cifs vfs is handling timestamps improperly.
>> Regarding legacy servers, special copy operations just fail.
>> (the todays smbfs vs. cifs legacy problem)
>>
>> Test environment:
>>  - latest git cifs vfs is mounted against
>>     - winNT
>>     - WinXP
>>     - OS/2
>>     - Win98SE
>>
>> Unfortunately, this one cannot be simply explained in 3 words ...
>> ----------------------------
>>
>> To make it as clear as possible - the mount commands:
>> *****************************************************
>> WinNT server:
>> =============
>> mount -t cifs //wrkgk/test /mnt/winnt -o cred=/root/sec/sec_gk,dir_mode=0775,file_mode=0764,uid=gk,gid=users
>>
>> WinXP server:
>> =============
>> mount -t cifs //cboyer/gk /mnt/winxp -o cred=/root/sec/sec_gk,dir_mode=0775,file_mode=0764,uid=gk,gid=users
>>
>> OS/2 server:
>> ============
>> mount -t cifs //server01/CIFS /mnt/server -o cred=/root/sec/sec_gk,sec=lanman,servern=SERVER01,port=139,dir_mode=0775,file_mode=0764,uid=gk,gid=users
>>
>> Win98SE:
>> ========
>> mount -t cifs //win98/CIFS /mnt/win9x -o cred=/root/sec/sec_gk,servern=WIN98,dir_mode=0775,file_mode=0764,uid=gk,gid=users
>>
>> ------------------------------------------------------
>>
>> The results of "cp -p local_file /mnt/some_server":
>> ***************************************************
>> NOTE:
>>    cp -p src dst
>> the '-p' option should preserve time stamps - at least the
>> last modification time!
>>
>> WinNT:
>> ======
>> gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/winnt/ && sleep 1 && stat /mnt/winnt/dummy.tst
>>   File: `dummy.tst'
>>   Size: 51078           Blocks: 104        IO Block: 4096   regular file
>> Device: 306h/774d       Inode: 1054939     Links: 1
>> Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
>> Access: 2008-07-09 04:32:26.000000000 +0200
>> Modify: 2007-05-07 21:52:40.000000000 +0200
>> Change: 2008-07-09 04:32:24.000000000 +0200
>>   File: `/mnt/winnt/dummy.tst'
>>   Size: 51078           Blocks: 104        IO Block: 16384  regular file
>> Device: 10h/16d Inode: 11749       Links: 1
>> Access: (0764/-rwxrw-r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
>> Access: 2008-07-09 04:35:06.854217400 +0200   !!!!!!!!!!!!!!!!!!!!!
>> Modify: 2008-07-09 04:35:06.794122600 +0200   !!!!!!!!!!!!!!!!!!!!!
>> Change: 2008-07-09 04:35:06.794122600 +0200   !!!!!!!!!!!!!!!!!!!!!
>>
>> WinXP:
>> ======
>> gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/winxp/ && sleep 1 && stat /mnt/winxp/dummy.tst
>>   File: `dummy.tst'
>>   Size: 51078           Blocks: 104        IO Block: 4096   regular file
>> Device: 306h/774d       Inode: 1054939     Links: 1
>> Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
>> Access: 2008-07-09 04:32:24.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
>> Modify: 2007-05-07 21:52:40.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
>> Change: 2008-07-09 04:32:24.000000000 +0200  !!!!!!!!!!!!!!!!!!!!!!!!
>>   File: `/mnt/winxp/dummy.tst'
>>   Size: 51078           Blocks: 104        IO Block: 16384  regular file
>> Device: 11h/17d Inode: 11484       Links: 1
>> Access: (0764/-rwxrw-r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
>> Access: 2008-07-09 04:31:31.012852800 +0200
>> Modify: 2008-07-09 04:31:31.012852800 +0200
>> Change: 2008-07-09 04:31:31.012852800 +0200
>>
>> OS/2:
>> =====
>> gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/server/ && sleep 1 && stat /mnt/server/dummy.tst
>>   File: `dummy.tst'
>>   Size: 51078           Blocks: 104        IO Block: 4096   regular file
>> Device: 306h/774d       Inode: 1054939     Links: 1
>> Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
>> Access: 2008-07-09 04:46:16.000000000 +0200
>> Modify: 2007-05-07 21:52:40.000000000 +0200
>> Change: 2008-07-09 04:32:24.000000000 +0200
>> cp: preserving times for `/mnt/server/dummy.tst': Invalid argument
>>
>> Win98SE:
>> ========
>> gk@linux700:~/cifstest> stat dummy.tst && cp -p dummy.tst /mnt/win9x/ && sleep 1 && stat /mnt/win9x/dummy.tst
>>   File: `dummy.tst'
>>   Size: 51078           Blocks: 104        IO Block: 4096   regular file
>> Device: 306h/774d       Inode: 1054939     Links: 1
>> Access: (0644/-rw-r--r--)  Uid: ( 1000/      gk)   Gid: (  100/   users)
>> Access: 2008-07-09 04:36:04.000000000 +0200
>> Modify: 2007-05-07 21:52:40.000000000 +0200
>> Change: 2008-07-09 04:32:24.000000000 +0200
>> cp: preserving times for `/mnt/win9x/dummy.tst': Invalid argument
>> -----------------------------------------------------------------
>>
>> Conclusion:
>> ===========
>> WinNT and WinXP just _silently_ FAIL!
>> OS/2 and Win98SE just fail with an error msg!
>>
>> All this is "a known cifs failure" for weeks now - Jeff Layton
>> has prepared a (large) patch to "cleanup the cifs_setattr()"
>> stuff - and I'm waiting to post more legacy functionality.
>>
>> ... but nothing happens ...
>>
>> A really sad situation, when realizing that even the samba
>> smbfs helpers smbmount, smbmnt and smbumount have now been
>> removed in 3.2.x.
>>
>> Cheers, Günter
>
>
> Hi Günter,
>
> I think Steve is on holiday this week (it's summer holiday season here
> in the US). I think he's waiting for 2.6.26 to be released before
> committing more patches. IMO, If you have patches you're just sitting
> on, then go ahead and post them and just make it clear that they depend
> on other, uncommitted patches. I'm working on some other things too and
> I'd like to make sure what I'm doing doesn't conflict with your work
> (or anyone else's), and that we're not duplicating each others efforts.
>
> As a side note, it might be nice if Steve had a "devel" branch in his
> git tree for stuff intended for the next release so that development
> could more easily continue during the mainline -rc phases. Of course, I
> need to get to work on a hosted git tree of my own as well ;-)
>
> --
> Jeff Layton <jlayton@...>
>

--
Thanks,

Steve
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Suresh Jayaraman-2]

Steve French wrote:
> Starting to catchup now.   I like the idea of having a devel branch
> that anyone could push to but not sure the easiest way to handle this.


Yeah, I think it is a good idea to have a devel branch. I can think of
two approaches which might be suitable.

1. We could have a shared central repository where multiple developers
can push changes (via SSH) to devel branch. But those primary developers
will need to have SSH access. An sample workflow:

- Developer clones the repo and setup a local working branch
- Developer makes changes and tests, gets it reviewed, sign-off
- Developer prepares a branch to push
     * switches to that branch
     * git format patch (redirect as a file)
     * git applymbox
- Developer pushes changes via SSH to the devel branch (Rebase if required)
- Delete the branch which was pushed, once we're done with it

Note: we need to make sure we are pushing only the prepared branch and
not master (explicitly specify the local and the remote branch)

2. Alternatively, as Jeff hinted, developers can have their own public
hosted trees and once the feature/work is completed/tested/reviwed
developers can request for a pull. The responsibility of keeping their
tree up-to-date with the Maintainer's tree lies with the developers.

Thoughts? Comments?


Thanks,

> On Wed, Jul 9, 2008 at 6:02 AM, Jeff Layton <jlayton@...> wrote:
>> On Wed, 9 Jul 2008 05:55:34 +0200
>> G�nter Kukkukk <linux@...> wrote:
>>
>>> I post that here - so it's not going to be forgotten.
>>>
>>> Again and again there are posts to many mailing lists,
>>> that cifs vfs is handling timestamps improperly.
>>> Regarding legacy servers, special copy operations just fail.
>>> (the todays smbfs vs. cifs legacy problem)
>>>

>>> All this is "a known cifs failure" for weeks now - Jeff Layton
>>> has prepared a (large) patch to "cleanup the cifs_setattr()"
>>> stuff - and I'm waiting to post more legacy functionality.
>>>
>>> ... but nothing happens ...
>>>
>>> A really sad situation, when realizing that even the samba
>>> smbfs helpers smbmount, smbmnt and smbumount have now been
>>> removed in 3.2.x.
>>>
>>> Cheers, G�nter
>>
>> Hi G�nter,
>>
>> I think Steve is on holiday this week (it's summer holiday season here
>> in the US). I think he's waiting for 2.6.26 to be released before
>> committing more patches. IMO, If you have patches you're just sitting
>> on, then go ahead and post them and just make it clear that they depend
>> on other, uncommitted patches. I'm working on some other things too and
>> I'd like to make sure what I'm doing doesn't conflict with your work
>> (or anyone else's), and that we're not duplicating each others efforts.
>>
>> As a side note, it might be nice if Steve had a "devel" branch in his
>> git tree for stuff intended for the next release so that development
>> could more easily continue during the mainline -rc phases. Of course, I
>> need to get to work on a hosted git tree of my own as well ;-)
>>
>> --
>> Jeff Layton <jlayton@...>

--
Suresh Jayaraman
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Fri, 25 Jul 2008 11:34:57 +0530
Suresh Jayaraman <sjayaraman@...> wrote:

> Steve French wrote:
> > Starting to catchup now.   I like the idea of having a devel branch
> > that anyone could push to but not sure the easiest way to handle this.
>
>
> Yeah, I think it is a good idea to have a devel branch. I can think of
> two approaches which might be suitable.
>
> 1. We could have a shared central repository where multiple developers
> can push changes (via SSH) to devel branch. But those primary developers
> will need to have SSH access. An sample workflow:
>
> - Developer clones the repo and setup a local working branch
> - Developer makes changes and tests, gets it reviewed, sign-off
> - Developer prepares a branch to push
>      * switches to that branch
>      * git format patch (redirect as a file)
>      * git applymbox
> - Developer pushes changes via SSH to the devel branch (Rebase if required)
> - Delete the branch which was pushed, once we're done with it
>
> Note: we need to make sure we are pushing only the prepared branch and
> not master (explicitly specify the local and the remote branch)
>
> 2. Alternatively, as Jeff hinted, developers can have their own public
> hosted trees and once the feature/work is completed/tested/reviwed
> developers can request for a pull. The responsibility of keeping their
> tree up-to-date with the Maintainer's tree lies with the developers.
>
> Thoughts? Comments?
>
>
> Thanks,
>

My preference would be for #2 here. I'm working on getting a public
git tree, but it may be a bit before I get it going. It'll probably
also take me a bit to get the workflow down correctly, etc.

Either way though, it's clear that we need to change our development
model some. The 2.6.27 merge window just closed, and very few of the
patches that were queued up before it opened have been merged.

It's not really possible to get these patches reviewed and merged into
Steve's tree and then get them pushed to mainline in the short merge
window. Ideally, we'd have them all in a branch ready to be pulled into
mainline when the merge window opens.

Having a devel branch would also expand testing of these patches, and
give us good way to get them into linux-next.

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Günter Kukkukk-2]

Am Dienstag, 29. Juli 2008 schrieb Jeff Layton:

> On Fri, 25 Jul 2008 11:34:57 +0530
> Suresh Jayaraman <sjayaraman@...> wrote:
>
> > Steve French wrote:
> > > Starting to catchup now.   I like the idea of having a devel branch
> > > that anyone could push to but not sure the easiest way to handle this.
> >
> >
> > Yeah, I think it is a good idea to have a devel branch. I can think of
> > two approaches which might be suitable.
> >
> > 1. We could have a shared central repository where multiple developers
> > can push changes (via SSH) to devel branch. But those primary developers
> > will need to have SSH access. An sample workflow:
> >
> > - Developer clones the repo and setup a local working branch
> > - Developer makes changes and tests, gets it reviewed, sign-off
> > - Developer prepares a branch to push
> >      * switches to that branch
> >      * git format patch (redirect as a file)
> >      * git applymbox
> > - Developer pushes changes via SSH to the devel branch (Rebase if required)
> > - Delete the branch which was pushed, once we're done with it
> >
> > Note: we need to make sure we are pushing only the prepared branch and
> > not master (explicitly specify the local and the remote branch)
> >
> > 2. Alternatively, as Jeff hinted, developers can have their own public
> > hosted trees and once the feature/work is completed/tested/reviwed
> > developers can request for a pull. The responsibility of keeping their
> > tree up-to-date with the Maintainer's tree lies with the developers.
> >
> > Thoughts? Comments?
> >
> >
> > Thanks,
> >
>
> My preference would be for #2 here. I'm working on getting a public
> git tree, but it may be a bit before I get it going. It'll probably
> also take me a bit to get the workflow down correctly, etc.
>
> Either way though, it's clear that we need to change our development
> model some. The 2.6.27 merge window just closed, and very few of the
> patches that were queued up before it opened have been merged.
>
> It's not really possible to get these patches reviewed and merged into
> Steve's tree and then get them pushed to mainline in the short merge
> window. Ideally, we'd have them all in a branch ready to be pulled into
> mainline when the merge window opens.
>
> Having a devel branch would also expand testing of these patches, and
> give us good way to get them into linux-next.
>

to my best knowledge, there are only a few developers (3...5 ?), which
_actively_ work on improvements of the cifs code.

Anyway - in all cases Steve decides, which patches should went
upstream - or not.

So all the burden to deliver a working quality kernel module
is focussed on Steve's "overall knowledge about ongoing change
requests - or even radical changes to the code base at all".

Ouch - not an easy task!

I think, _one_ new additional public cifs git tree for developers
should be enough - probably combined with some really needed talks
on IRC - to coordinate "all the change requests" ...

I really would prefer irc channel #samba-technical - but a
separate channel #cifs-technical could also be a choice.

Cheers, Günter
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Sat, 2 Aug 2008 07:50:23 +0200
Günter Kukkukk <linux@...> wrote:

> Am Dienstag, 29. Juli 2008 schrieb Jeff Layton:
> > On Fri, 25 Jul 2008 11:34:57 +0530
> > Suresh Jayaraman <sjayaraman@...> wrote:
> >
> > > Steve French wrote:
> > > > Starting to catchup now.   I like the idea of having a devel branch
> > > > that anyone could push to but not sure the easiest way to handle this.
> > >
> > >
> > > Yeah, I think it is a good idea to have a devel branch. I can think of
> > > two approaches which might be suitable.
> > >
> > > 1. We could have a shared central repository where multiple developers
> > > can push changes (via SSH) to devel branch. But those primary developers
> > > will need to have SSH access. An sample workflow:
> > >
> > > - Developer clones the repo and setup a local working branch
> > > - Developer makes changes and tests, gets it reviewed, sign-off
> > > - Developer prepares a branch to push
> > >      * switches to that branch
> > >      * git format patch (redirect as a file)
> > >      * git applymbox
> > > - Developer pushes changes via SSH to the devel branch (Rebase if required)
> > > - Delete the branch which was pushed, once we're done with it
> > >
> > > Note: we need to make sure we are pushing only the prepared branch and
> > > not master (explicitly specify the local and the remote branch)
> > >
> > > 2. Alternatively, as Jeff hinted, developers can have their own public
> > > hosted trees and once the feature/work is completed/tested/reviwed
> > > developers can request for a pull. The responsibility of keeping their
> > > tree up-to-date with the Maintainer's tree lies with the developers.
> > >
> > > Thoughts? Comments?
> > >
> > >
> > > Thanks,
> > >
> >
> > My preference would be for #2 here. I'm working on getting a public
> > git tree, but it may be a bit before I get it going. It'll probably
> > also take me a bit to get the workflow down correctly, etc.
> >
> > Either way though, it's clear that we need to change our development
> > model some. The 2.6.27 merge window just closed, and very few of the
> > patches that were queued up before it opened have been merged.
> >
> > It's not really possible to get these patches reviewed and merged into
> > Steve's tree and then get them pushed to mainline in the short merge
> > window. Ideally, we'd have them all in a branch ready to be pulled into
> > mainline when the merge window opens.
> >
> > Having a devel branch would also expand testing of these patches, and
> > give us good way to get them into linux-next.
> >
>
> to my best knowledge, there are only a few developers (3...5 ?), which
> _actively_ work on improvements of the cifs code.
>
> Anyway - in all cases Steve decides, which patches should went
> upstream - or not.
>
> So all the burden to deliver a working quality kernel module
> is focussed on Steve's "overall knowledge about ongoing change
> requests - or even radical changes to the code base at all".
>
> Ouch - not an easy task!
>
> I think, _one_ new additional public cifs git tree for developers
> should be enough - probably combined with some really needed talks
> on IRC - to coordinate "all the change requests" ...
>
> I really would prefer irc channel #samba-technical - but a
> separate channel #cifs-technical could also be a choice.
>

I also don't envy Steve's task, which is why I'd like to see us use the
tools to make it easier for him...

My idea about having my own git tree is really just as an
organizational tool to make it easier for me to feed patches to him. I
tend to push quite a few patches to Steve and keeping them organized in
email is tough. If I were to host a "for-cifs-devel" branch on my git
tree that has patches that I'm ready to push to Steve then that makes
it easier for him to pull them into his tree. For people who post
patches only occasionally, it's probably not as useful and the list is
fine.

I don't think anyone else but Steve would be a "consumer" of my tree.
What would be nice though is an extra devel or test branch in Steve's
tree for active development. Steve could pull new patches into that
branch without fear of breaking the "main" branch that he feeds to
Linus. As patches mature in that branch they could then be moved to a
"for-linux-next" branch and then eventually a "for-linus" branch...

The details of this are really up to him, but I do think that we need
some mechanism to keep patches from just sitting on the mailing list.
Right now, they're just not getting the testing exposure that they
should...

Coordination via IRC would also be a good thing. #samba-technical works
for me too. We can always open a new channel if that becomes too messy.

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Steve French-2]

Now that OLS is over, if it would help I can get on samba-technical
irc during the afternoons/early evening (central time) to discuss
patches.  It would probably help with testing OS/2 related patches in
realtime because I only have occassional access.

On Sat, Aug 2, 2008 at 12:50 AM, Günter Kukkukk <linux@...> wrote:

> Am Dienstag, 29. Juli 2008 schrieb Jeff Layton:
>> On Fri, 25 Jul 2008 11:34:57 +0530
>> Suresh Jayaraman <sjayaraman@...> wrote:
>
> I think, _one_ new additional public cifs git tree for developers
> should be enough - probably combined with some really needed talks
> on IRC - to coordinate "all the change requests" ...
>
> I really would prefer irc channel #samba-technical - but a
> separate channel #cifs-technical could also be a choice.
>
> Cheers, Günter
>

--
Thanks,

Steve
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Steve French-2]

On Sat, Aug 2, 2008 at 6:04 AM, Jeff Layton <jlayton@...> wrote:
> I also don't envy Steve's task, which is why I'd like to see us use the
> tools to make it easier for him...
The biggest two things that would help me are simple a) all patches in
"git-am" form
so I can apply them immediately if the review passes b) a place to dump
places (anonynmous ftp would be fine) tmp-directory - where I could
move patches into different subdirs (or mark them)
based on status e.g. "deferred", "not-reviewed",  "additional review needed",
or "need changes" (e.g.the patch won't merge cleanly or would
be improved with changes)

>
> My idea about having my own git tree is really just as an
> organizational tool to make it easier for me to feed patches to him. I
> tend to push quite a few patches to Steve and keeping them organized in
> email is tough. If I were to host a "for-cifs-devel" branch on my git
> tree that has patches that I'm ready to push to Steve then that makes
> it easier for him to pull them into his tree. For people who post
> patches only occasionally, it's probably not as useful and the list is
> fine.
>
> I don't think anyone else but Steve would be a "consumer" of my tree.
> What would be nice though is an extra devel or test branch in Steve's
> tree for active development. Steve could pull new patches into that
> branch without fear of breaking the "main" branch that he feeds to
> Linus. As patches mature in that branch they could then be moved to a
> "for-linux-next" branch and then eventually a "for-linus" branch...
>
> The details of this are really up to him, but I do think that we need
> some mechanism to keep patches from just sitting on the mailing list.
> Right now, they're just not getting the testing exposure that they
> should...
>
> Coordination via IRC would also be a good thing. #samba-technical works
> for me too. We can always open a new channel if that becomes too messy.
>
> --
> Jeff Layton <jlayton@...>
>

--
Thanks,

Steve
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Sat, 2 Aug 2008 12:28:27 -0500
"Steve French" <smfrench@...> wrote:

> On Sat, Aug 2, 2008 at 6:04 AM, Jeff Layton <jlayton@...> wrote:
> > I also don't envy Steve's task, which is why I'd like to see us use the
> > tools to make it easier for him...
> The biggest two things that would help me are simple a) all patches in
> "git-am" form
> so I can apply them immediately if the review passes

By "git-am form", I presume you mean that you want us to generate the
patches with "git-format-patch"? Any particular flags you want us to
use when generating these patches?

--
Jeff Layton <jlayton@...>
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Steve French-2]

git-format-patch with no options is fine with me (but not all patch
submitters are using git - I am not sure what is easiest for them),
This form saves time since it eliminates the steps of having to set
and then reset environment variables and avoids having to cut/paste
the commit description (and it also puts a more realistic changeset
date) - and by attaching the patch as an attachment to email it makes
it easier when I read gmail via the web (since the browser/gmail
modifying tabs/whitespace in the web email affects inline patches)

On Sat, Aug 2, 2008 at 8:07 PM, Jeff Layton <jlayton@...> wrote:

> On Sat, 2 Aug 2008 12:28:27 -0500
> "Steve French" <smfrench@...> wrote:
>
>> On Sat, Aug 2, 2008 at 6:04 AM, Jeff Layton <jlayton@...> wrote:
>> > I also don't envy Steve's task, which is why I'd like to see us use the
>> > tools to make it easier for him...
>> The biggest two things that would help me are simple a) all patches in
>> "git-am" form
>> so I can apply them immediately if the review passes
>
> By "git-am form", I presume you mean that you want us to genera