samba - May 2020 - Win7 clients problem after upgrading samba file server to 4.12 on Arch

sob., 9 maj 2020 o 10:34 Ralph Boehme <slow at samba.org> napisa?(a):
> Hi Pawel,
> Can you share a network trace and loglevel 10 debug log of a reproducer?
> The links you posted earlier don't seem to work anymore.
>
> -slow
>
...because I have treated them as not important and have deleted them,
after I had found the proper commit in code.
If this is important - I may reproduce them, this time tracing more
precisely moments of misbehavior.

Pawel.

Am 5/9/20 um 2:21 PM schrieb pavlos:
> sob., 9 maj 2020 o 10:34?Ralph Boehme <slow at samba.org
> <mailto:slow at samba.org>> napisa?(a):
> 
>     Hi Pawel,
>     Can you share a network trace and loglevel 10 debug log of a
reproducer?
>     The links you posted earlier don't seem to work anymore.
> 
>     -slow
> 
> ...because I have treated them as not important and have deleted them,
> after I had found the proper commit in code.
> If this is important - I may reproduce them, this time tracing more
> precisely moments of misbehavior. 
yes, this would be helpful. Otherwise I may end up fixing a bug which is
different then yours. :)

To be clear: if you're running into this issue that I'm seeing in the
code, then this is *not* a client side bug. It's a server bug that only
gets triggered by a specific access pattern. Likely Win 7 has a
different pattern compared to other Windows versions which explains why
you only see it there.

-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20200509/6aa11add/signature.sig>

sob., 9 maj 2020 o 14:37 Ralph Boehme <slow at samba.org> napisa?(a):
> To be clear: if you're running into this issue that I'm seeing in
the
> code, then this is *not* a client side bug. It's a server bug that only
> gets triggered by a specific access pattern. Likely Win 7 has a
> different pattern compared to other Windows versions which explains why
> you only see it there.
>
> -slow
>
>
Ralf,
Give me a while, I have to prepare the server moving it to the commit we
have our focus on.

Different patterns also observed between different file managers within the
same Windows session
I am historically using WIndows-only FreeCommander, recently switched to
multi-platform DoubleCommander. And I could observe different symptoms in
same use cases performed with three tools:

   - FreeCommander - it was usually "first detection tool" - could not
   expand folders of the share, not able to go into a subfolder, not showing
   files that should be visible
   - Windows Explorer - this tool could display a folder content, go into a
   subfolder, but any attempt to skip back two folders up in the address bar
   always was producing this funny message "*The process cannot access the
   file because it is being used by another process.*"
   - DoubleCommander - this was usually the most resistant file manager,
   still working after FC and WE refusing to work, of course also finally
   showing "unknown errors"

Use case scenarios were never the same: sometimes the server was refusing
any operation from the moment of connecting to the share, sometimes
misbehavior was observed after some time of normal functioning.
Wery strange, very unpredictable, not always easy reproducible...
As I have two Win7 boxes, I was always connecting one of them anonymously
in read-only mode, and the second using 'ala' read-write account.
In order to speed up my testing I was using cmd.exe command line to connect
and disconnect:
To connect:

   - R/W: net use y: \\192.168.1.116\nas /user:192.168.1.116\ala
<password>
   /persistent:yes
   - R/O: net use y: \\192.168.1.116\nas /persistent:yes

I was not storing 'ala' password in Credential Manager.
To Disconnect after testing:

   - net use y: /delete

I am writing about that - maybe it is important.

Thanks! Pawel.