Re: FindFirstFile fails for some network directories

2015-12-09 Thread Orgad Shaneh
On Wed, Aug 19, 2015 at 8:28 AM, Orgad Shaneh  wrote:
>
> On Wed, Aug 19, 2015 at 8:46 AM, Orgad Shaneh  wrote:
> > Working capture: https://gist.github.com/orgads/d2681881668afb9cb08f
> > Failing capture: https://gist.github.com/orgads/4f0ea2b26cfd64f4353d
>
> I just found another SMB1 linux server, which does work[1].
>
> It first has a "NT Create AndX" request for path \, which succeeds.
> Then it issues Trans2 FIND_FIRST2 request for the real path (\a).
>
> This issue might be related to the Archive bit which is set on aclnas01.
>
> - Orgad
>
> [1] https://gist.github.com/orgads/e76a00c2cc0fc8a43d95

Hi,

After investigation, I found that the root cause for this problem is
set_cygwin_privileges, which sets SE_RESTORE_PRIVILEGE and
SE_BACKUP_PRIVILEGE for the process during initialization.

Commenting out these 2 lines solves the problem for me.

Can you tell why are they needed at all? There is a comment there:

Allow to access all files, independent of their ACL settings.

What does it mean?

- Orgad

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: FindFirstFile fails for some network directories

2015-12-09 Thread Corinna Vinschen
On Dec  9 11:43, Orgad Shaneh wrote:
> On Wed, Aug 19, 2015 at 8:28 AM, Orgad Shaneh  wrote:
> >
> > On Wed, Aug 19, 2015 at 8:46 AM, Orgad Shaneh  wrote:
> > > Working capture: https://gist.github.com/orgads/d2681881668afb9cb08f
> > > Failing capture: https://gist.github.com/orgads/4f0ea2b26cfd64f4353d
> >
> > I just found another SMB1 linux server, which does work[1].
> >
> > It first has a "NT Create AndX" request for path \, which succeeds.
> > Then it issues Trans2 FIND_FIRST2 request for the real path (\a).
> >
> > This issue might be related to the Archive bit which is set on aclnas01.
> >
> > - Orgad
> >
> > [1] https://gist.github.com/orgads/e76a00c2cc0fc8a43d95
> 
> Hi,
> 
> After investigation, I found that the root cause for this problem is
> set_cygwin_privileges, which sets SE_RESTORE_PRIVILEGE and
> SE_BACKUP_PRIVILEGE for the process during initialization.
> 
> Commenting out these 2 lines solves the problem for me.
> 
> Can you tell why are they needed at all? There is a comment there:
> 
> Allow to access all files, independent of their ACL settings.
> 
> What does it mean?

These are the user privileges required to allow an admin user accessing
files which don't give him permissions to do so, just like a POSIX root
user.  The usual behaviour of a filesystem should be to refuse the
setting without to fail.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpC8FaoNRqYp.pgp
Description: PGP signature


Re: FindFirstFile fails for some network directories

2015-08-19 Thread Orgad Shaneh
On Wed, Aug 19, 2015 at 8:46 AM, Orgad Shaneh org...@gmail.com wrote:
 Working capture: https://gist.github.com/orgads/d2681881668afb9cb08f
 Failing capture: https://gist.github.com/orgads/4f0ea2b26cfd64f4353d

I just found another SMB1 linux server, which does work[1].

It first has a NT Create AndX request for path \, which succeeds.
Then it issues Trans2 FIND_FIRST2 request for the real path (\a).

This issue might be related to the Archive bit which is set on aclnas01.

- Orgad

[1] https://gist.github.com/orgads/e76a00c2cc0fc8a43d95

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: FindFirstFile fails for some network directories

2015-08-18 Thread Orgad Shaneh
On Mon, Aug 17, 2015 at 3:03 PM, Orgad Shaneh org...@gmail.com wrote:
 Hi,

 I have 2 network shares with similar contents:
 \\netapp1\CM\CompilationResults
 \\aclnas01\versions\CompilationResults

 Trying to list all the files within these directories using Ruby
 succeeds for netapp1, but fails for aclnas01.

 The failing ruby command is:
   ruby -e print Dir.glob('//aclnas01/versions/CompilationResults/*')

 The exact same command succeeds when executed from a normal command
 prompt, or when the directory is on netapp1 (on both shells).

 After debugging Ruby, I found out that FindFirstFile returns an
 INVALID_HANDLE when invoked from cygwin environment.

 The following application succeeds on command prompt and fails on cygwin:

 #include stdio.h
 #include windows.h

 int main()
 {
 const TCHAR *aclnas = TEXT(//aclnas01/versions/CompilationResults);
 const TCHAR *netapp = TEXT(//netapp1/CM/CompilationResults);

 WIN32_FIND_DATA fd;
 printf(%d\n, FindFirstFile(aclnas, fd) !=
 INVALID_HANDLE_VALUE); // Fails on cygwin
 printf(%d\n, FindFirstFile(netapp, fd) !=
 INVALID_HANDLE_VALUE); // Always succeeds
 return 0;
 }

 Output on cmd is 1 1, on cygwin it is 0 1.

 Process Monitor shows that when executed from cygwin, CreateFile is
 called with Open for Backup flag. I can't say for sure if this causes
 the failure, but that's the only difference I could find between these
 executions.

 This bug was previously reported on github/msys2[1], but it wasn't solved.

 I only have read access to these servers, but I might have cooperation
 of the sys admin (can't promise though).

 Any help will be appreciated.

 Thanks,
 - Orgad

 [1] https://github.com/Alexpux/MSYS2-packages/issues/242

Hi,

Using Wireshark, I discovered that aclnas01 uses SMB, while netapp1 uses SMB2.

For some reason, when executed from command prompt, a FIND_FIRST2
request is sent and the server replies, while with cygwin a NT Create
AndX request is sent and denied.

To minimize the captured packets, I executed the application twice,
and captured only the second execution (to avoid session initiation).

Working capture: https://gist.github.com/orgads/d2681881668afb9cb08f
Failing capture: https://gist.github.com/orgads/4f0ea2b26cfd64f4353d

Does cygwin implement SMB on its own, or is this difference a
side-effect of the Backup Intent flag?

- Orgad

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



FindFirstFile fails for some network directories

2015-08-17 Thread Orgad Shaneh
Hi,

I have 2 network shares with similar contents:
\\netapp1\CM\CompilationResults
\\aclnas01\versions\CompilationResults

Trying to list all the files within these directories using Ruby
succeeds for netapp1, but fails for aclnas01.

The failing ruby command is:
  ruby -e print Dir.glob('//aclnas01/versions/CompilationResults/*')

The exact same command succeeds when executed from a normal command
prompt, or when the directory is on netapp1 (on both shells).

After debugging Ruby, I found out that FindFirstFile returns an
INVALID_HANDLE when invoked from cygwin environment.

The following application succeeds on command prompt and fails on cygwin:

#include stdio.h
#include windows.h

int main()
{
const TCHAR *aclnas = TEXT(//aclnas01/versions/CompilationResults);
const TCHAR *netapp = TEXT(//netapp1/CM/CompilationResults);

WIN32_FIND_DATA fd;
printf(%d\n, FindFirstFile(aclnas, fd) !=
INVALID_HANDLE_VALUE); // Fails on cygwin
printf(%d\n, FindFirstFile(netapp, fd) !=
INVALID_HANDLE_VALUE); // Always succeeds
return 0;
}

Output on cmd is 1 1, on cygwin it is 0 1.

Process Monitor shows that when executed from cygwin, CreateFile is
called with Open for Backup flag. I can't say for sure if this causes
the failure, but that's the only difference I could find between these
executions.

This bug was previously reported on github/msys2[1], but it wasn't solved.

I only have read access to these servers, but I might have cooperation
of the sys admin (can't promise though).

Any help will be appreciated.

Thanks,
- Orgad

[1] https://github.com/Alexpux/MSYS2-packages/issues/242

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple