RE: SMBFS mount's file cannot be made executable

[KAVALAGIOS Panagiotis (EEAS-EXT)]

> Hi,
> 
> So nobody has any suggestions per this?
> 
> https://cygwin.com/ml/cygwin/2019-08/msg00126.html

That's strange. The execution of a file is also controlled by the way the 
filesystem is mounted and the execution permission granted by chmod is not 
enough. You need the "exec" mount option. On the drives that have the "user" 
option automatically implies noexec, nosuid, and nodev, unless overridden by 
the corresponding option without the "no" prefix.

The only issue I can see is that you can execute files on your U: drive and 
even on your Z: if you give permissions from Linux machine. Maybe Cygwin 
implementation is not so strict about the permissions.

Panos

--
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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1

[Corinna Vinschen]

On Aug 12 17:36, Corinna Vinschen wrote:
> On Aug 12 22:44, Takashi Yano wrote:
> > [...]
> > (4) Segmentation fault occurs in some cases regarding signalfd.
> > [...]
> > However, I can not find out the cause of problem (4). This seems
> > to affect only 32bit version of cygwin.
> > 
> > To reproduce (4), use a simple test case attached (signalfd-chk.c).
> > Compile it and execute, then type 'q' or '^C' to stop it.
> > This causes segmentation fault.
> > 
> > I am not sure why, but, the patch attached (signalfd-segfault.diff)
> > resolves the problem (4).
> > 
> > Could you please have a look?
> 
> Will do.  The place where it supposedly crashes looks weird.  But
> I don't see how your patch should be the right thing to do.

I created a patch which *seems* to do the right thing.  I'm not
yet sure it's the best solution, but it seems to do the trick, at
least.

I'm just creating new developer snapshots, please try.  I'll
create another test release later this week.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: mq_notify api of mqueue.h does not work

[Corinna Vinschen]

On Aug 12 23:32, nilesh gharde wrote:
> Hi,
> 
> I am using windows 10 and installed msys2 which internally uses "Cygwin
> code base" to have ENV same as my linux machine.
> I have implemented an IPC mechanism based on mqueue Apis. I see few mqueue
> api's work properly like create and send as I can see the "/my_queue_name"
> gets created under "/dev/mqueue/my_queue_name" and I see some data which I
> put there. But I see the behavior is kind of diff with msys2 on windows.
> 
> Windows Machine:
> $ ls -ltr
> total 4
> -rw-r--r-- 1 ngharde Domain Users 1296 Aug 11 17:58 Niles
> $ cat Niles
> d▒▒1F734DB930DC569D1B1061BF▒) @2tv ▒▒This
> is nilesh string onep"This is
> nilesh stting two nfnslfn"This is nilesh stting two nfnslfnX▒@▒(▒
> [When I do cat I see this crap + my added data with send API]
> 
> LINUX machine Ubuntu 16.04.6 LTS
> >ls -ltr
> total 0
> -rw-r--r-- 1 ngharde users 80 Aug 5 19:27 Niles
> > cat Niles
> QSIZE:0 NOTIFY:0 SIGNO:0 NOTIFY_PID:0
> [Here I see info. about which PID is kind of waiting on this queue to get
> notified ]
> 
> The behavior where a process subscribe to get notified if there some msg in
> the queue kind of works correctly in my Linux machine, but on windows with
> msys2 that behavior I am not able to achieve.
> code path:
> https://github.com/Nilesh1992/Personal_Project/blob/master/mq_ipc/src/mq_ipccore.cpp
> 
> Thanks in advance!

Can you please create a simple, self-contained testcase in plain C?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Hung setup-x86_64.exe after parsing setup.ini

[Jon Turney]

On 12/08/2019 10:44, Веснин Юрий Александрович wrote:


After creating a huge custom package, we meet inaccessibility of using 
setup.exe. It hangs on parsing setup.ini. By doing a little research we've 
found that this behavior appears when package size is greater than 1GiB (not 
accurate 1GiB but 1.4GB is enough). We started to investigate setup.exe sources 
but we stuck in bison sources.


If you provide more details on that problem, I can probably give some 
advice.



How to reproduce the problem:
1. Make own FTP-repo of Cygwin (I think it could be done without packages at 
all)
2. Append the addition to setup.ini (from bottom of letter; in my setup.ini it 
holds from 173244 line)
3. Compress one with setup
4. Start latest (2.897 | 64 bit) setup-x86_64.exe, try to use this repo with 
default other settings.
5. The freeze happens during parsing setup.xz

"Workaround" is
1. Replace actual size with 10 (at 173260th line of my setup.ini)
2. Recompress one
3. Start same setup utility
4. Parsing setup.xz passed but it breaks by downloading, of course. It's OK.

It's definitely a bug. What's the proper way to fix it?


Odd.

I suspect that there might be additional problems later on, if the 
uncompressed size of the package exceeds 2GB (as briefly mentioned in [1])


[1] https://cygwin.com/ml/cygwin-apps/2013-01/msg00045.html

--
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: SMBFS mount's file cannot be made executable

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

Thanks for responding!

> You need the "exec" mount option.

I thought so too, but how do I give that option to a drive that is "noumount".  
I cannot dis- or re-mount it AFAICT.

$ mount
...
Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
$ umount /cygdrive/z
umount: /cygdrive/z: Invalid argument

Also, I tried to mount the same path elsewhere, and with the "exec" options, 
and that wouldn't help, either:

$ mount -o exec //coredev2/home/lavr /mnt
$ mount
//coredev2/home/lavr on /mnt type smbfs (binary,exec,user)
...
$ cd /mnt
$ pwd
/mnt
$ gcc a.c
$ ls -l a.exe
-rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe
$ ./a.exe
-bash: ./a.exe: Permission denied
(and again, if a.exe is given the "x" perm in the Linux fs, the command above 
works)

I think that something's wrong with how (or if) Cygwin translates the "x" unix 
execution permission bit to an ACL that is passed thru SMB -- it does not get 
transferred to the Linux side correctly.  But if set there, then it gets 
converted to the execute ACL the right way, and that makes the file executable 
on the Windows side...  I do not know how is it all implemented, though;  it's 
just my observation.


--
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: Hung setup-x86_64.exe after parsing setup.ini

[Веснин Юрий Александрович]

> If you provide more details on that problem, I can probably give some 
> advice.

I suppose that bug comes from parsing setup.ini because of cygwin hangs on such 
stage.
You can find more details by following previously described steps.

>> How to reproduce the problem:
>> 1. Make own FTP-repo of Cygwin (I think it could be done without packages at 
>> all)
>> 2. Append the addition to setup.ini (from the bottom of letter; in my 
>> setup.ini it holds from 173244 line)
>> 3. Compress one with setup
>> 4. Start latest (2.897 | 64 bit) setup-x86_64.exe, try to use this repo with 
>> default other settings.
>> 5. The freeze happens during parsing setup.xz
>> 
>> "Workaround" is
>> 1. Replace actual size with 10 (at 173260th line of my setup.ini)
>> 2. Recompress one
>> 3. Start same setup utility
>> 4. Parsing setup.xz passed but it breaks by downloading, of course. It's OK.
>> 
>> It's definitely a bug. What's the proper way to fix it?

> Odd.

> I suspect that there might be additional problems later on, if the 
> uncompressed size of the package exceeds 2GB (as briefly mentioned in [1])

Definitely not. Setup utility does not reach the downloading stage.

> [1] https://cygwin.com/ml/cygwin-apps/2013-01/msg00045.html

--
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: Hung setup-x86_64.exe after parsing setup.ini

[Jon Turney]

On 13/08/2019 17:56, Веснин Юрий Александрович wrote:

If you provide more details on that problem, I can probably give some
advice.


I suppose that bug comes from parsing setup.ini because of cygwin hangs on such 
stage.
You can find more details by following previously described steps.
You wrote: "We started to investigate setup.exe sources but we stuck in 
bison sources."


I have no idea what kind of problem you encountered trying to 
investigate the problem.  Unless you provide more details about what you 
got stuck on, I can't help you very much.


--
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: SMBFS mount's file cannot be made executable

[Achim Gratz]

Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin writes:
> I think that something's wrong with how (or if) Cygwin translates the
> "x" unix execution permission bit to an ACL that is passed thru SMB --
> it does not get transferred to the Linux side correctly.  But if set
> there, then it gets converted to the execute ACL the right way, and
> that makes the file executable on the Windows side...  I do not know
> how is it all implemented, though; it's just my observation.

If it's related to the ACL handling then it should start working when
you remove the ACL on the file with 'setfacl -kb …'.  On the other hand
you mentioned NetApp, and these can be set up to completely ignore
certain DACL, mode or owner changes from clients (with or without
raising errors while doing so).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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: SMBFS mount's file cannot be made executable

[Andrey Repin]

Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]!

>> You need the "exec" mount option.

> I thought so too, but how do I give that option to a drive that is
> "noumount".  I cannot dis- or re-mount it AFAICT.

> $ mount
> ...
> Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto)
> $ umount /cygdrive/z
> umount: /cygdrive/z: Invalid argument

/cygdrive is automount.
What is your cygdrive mount options? Because default is, apparently, 
"binary,posix=0,user".

> Also, I tried to mount the same path elsewhere, and with the "exec"
> options, and that wouldn't help, either:

> $ mount -o exec //coredev2/home/lavr /mnt
> $ mount
> //coredev2/home/lavr on /mnt type smbfs (binary,exec,user)
> ...
> $ cd /mnt
> $ pwd
> /mnt
> $ gcc a.c
> $ ls -l a.exe
> -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe
> $ ./a.exe
> -bash: ./a.exe: Permission denied
> (and again, if a.exe is given the "x" perm in the Linux fs, the command above 
> works)

> I think that something's wrong with how (or if) Cygwin translates the "x"
> unix execution permission bit to an ACL that is passed thru SMB -- it does
> not get transferred to the Linux side correctly.  But if set there, then it
> gets converted to the execute ACL the right way, and that makes the file
> executable on the Windows side...  I do not know how is it all implemented, 
> though;  it's just my observation.


-- 
With best regards,
Andrey Repin
Tuesday, August 13, 2019 21:22:07

Sorry for my terrible english...


--
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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1

[Thorsten Kampe]

* Corinna Vinschen (Mon, 12 Aug 2019 15:01:52 +0200)
> 
> On Aug 11 09:27, Thorsten Kampe wrote:
> > * Corinna Vinschen (Fri, 9 Aug 2019 20:53:38 +0200)
> > > I uploaded a new Cygwin test release 3.1.0-0.1
> > > 
> > > This release comes with a couple of new features and quite a few
> > > bug fixes.
> > > 
> > > The most interesting change, courtesy Ken Brown, is a revamp of the
> > > old FIFO code.  It should now be possible to open FIFOs multiple times
> > > for writing, something the old code failed on.
> > 
> > I've noticed two things in connection with pspg 
> > (https://github.com/okbob/pspg) - a pager for tables:
> 
> Nobody from the dev team uses this application, afaics.
> 
> To help tracking down the cause for the problems, can you bisect
> Cygwin or at least check which of the snapshots from
> http://www.cygwin.com/snapshots/ introduces the problem?

The issue is definitely not just with ConEmu but also with a 
standard Windows console (cmd.exe).

I compiled tree 
(http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz).

Mintty: 2.5s
Cmd: 122s

Make clean[1]:
Mintty: 0.3s
Cmd: 60,3s


Thorsten

[1]
if [ -x tree ]; then rm tree; fi
if [ -f tree.o ]; then rm *.o; fi
rm -f *~


--
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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1

[Thorsten Kampe]

* Thorsten Kampe (Tue, 13 Aug 2019 23:45:14 +0200)
> The issue is definitely not just with ConEmu but also with a 
> standard Windows console (cmd.exe).
> 
> I compiled tree 
> (http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz).
> 
> Mintty: 2.5s
> Cmd: 122s
> 
> Make clean[1]:
> Mintty: 0.3s
> Cmd: 60,3s

A second compile took even three minutes:
real3m1,822s
user0m1,158s
sys 0m0,751s

The times in Mintty:
real0m2,281s
user0m1,006s
sys 0m0,844s

Note that user and sys are almost identical in Cmd and Mintty. 
Only real differs.

Thorsten


--
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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1

[Thorsten Kampe]

* Takashi Yano (Tue, 13 Aug 2019 04:44:51 +0900)
> I looked into this problem, and found that this is due to a
> bug of ConEmu.
> 
> Attached is the simple test case (conemu-chk.c).
> In command prompt, the output of this program is:
> AAA
> BBB
> 
> However, in ConEmu, the output is:
> AAA
>BBB
> 
> If ENABLE_VIRTUAL_TERMINAL_INPUT flag is set to console input,
> it affects to console output and becomes so that the newline '\n'
> does not cause carriage return. This is weird.
> 
> Thorsten, could you please report this bug to ConEmu developers?

Thanks, I've opened #1966 
(https://github.com/Maximus5/ConEmu/issues/1966)

Thorsten


--
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: SMBFS mount's file cannot be made executable

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

> What is your cygdrive mount options? Because default is, apparently, 
> "binary,posix=0,user".

I have no idea where they are kept at, and how to change them.

Also, I couldn't make this work, anyways; yet I thought it should have worked:

> > $ mount -o exec //coredev2/home/lavr /mnt
> > $ mount
> > //coredev2/home/lavr on /mnt type smbfs (binary,exec,user)
> > ...
> > $ cd /mnt
> > $ pwd
> > /mnt
> > $ gcc a.c
> > $ ls -l a.exe
> > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe
> > $ ./a.exe
> > -bash: ./a.exe: Permission denied


--
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: SMBFS mount's file cannot be made executable

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

> If it's related to the ACL handling then it should start working when
> you remove the ACL on the file with 'setfacl -kb ...'

There are no special ACLs set on the file (that was just produced by GCC from 
the source code, see my first email).

But I am now convinced that the problem is _entirely_ in Cygwin's corner:

When I open that file's the "Properties->Security" Windows tab, I can see that 
my permissions are "Read" and "Write", yet
"Read & Execute" is NOT checked.  When I check it, I see that the file becomes 
executable (the "x" bit) from both
Cygwin shell and on the Linux side, too.  And after that, I can execute the 
file from the Cygwin shell.

So what happens is that when "chmod" (or "creat" with a permission mask) is 
called, Cygwin does not honor the "x" bit(s) and does not convert it to
a corresponding proper ACL for the Windows mounted filesystem (and that ACL, in 
turn, would have been then sent to SMBD to get converted there back
to the "x" bit in the Unix world).  Once the "x" is there, Windows(via SMBD) 
obviously allows execution of the image.  Here's a related "bug":

https://forge.univention.org/bugzilla/show_bug.cgi?id=33785

I did not investigate in details how Cygwin handles the execute permission, but 
obviously there's something off.


--
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: SMBFS mount's file cannot be made executable

[Ken Brown]

On 8/13/2019 8:53 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
>> If it's related to the ACL handling then it should start working when
>> you remove the ACL on the file with 'setfacl -kb ...'
> 
> There are no special ACLs set on the file (that was just produced by GCC from 
> the source code, see my first email).

Have you checked the default ACL on the directory containing the file?

Ken

--
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: SMBFS mount's file cannot be made executable

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

> Have you checked the default ACL on the directory containing the file?

No, and there's nothing special there now that I checked.  I can change the 
"Read & Execute" for the .exe file from the Windows file properties
without having to deal with anything special or additional (like inherited 
permissions), so I don't think the containing directory has anything
to do with it.

$ getfacl /cygdrive/z
# file: /cygdrive/z
# owner: lavr
# group: cppcore
user::rwx
group::r-x
other::r-x
getfacl: /cygdrive/z: Invalid argument

$ getfacl.exe /mnt
# file: /mnt
# owner: lavr
# group: cppcore
user::rwx
group::r-x
other::r-x
getfacl: /mnt: Invalid argument

(where /mnt is the same network share mounted with the "exec" option, see 
previous posts;  not sure what EINVAL means there in the output,
it does not appear for files -- seems to be only when directories are inquired)


--
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: Inefficient use of 64-bit addresses in Clang

[Agner Fog]

It's a difference in memory model.

clang 6.0.0 under ubuntu with --target=x86_64-pc-cygwin gives relative 
addresses, unless you specify -mcmodel=large.


Cygwin clang with -mcmodel=small does the right thing: use relative 
addresses.


The -mcmodel=small option appears to work differently for Linux and for 
Windows targets. I cannot find any documentation of this difference. See:


https://bugs.llvm.org/show_bug.cgi?id=42983


On 12/08/2019 11.45, falk.tannhau...@free.fr wrote:

References: <578eb489-9391-9009-82ad-676eeb4c1...@agner.org>
In-Reply-To: <578eb489-9391-9009-82ad-676eeb4c1...@agner.org>

Could the different behaviour between Cygwin and Linux simply be due to 
different Clang versions?
The current version under Cygwin is 5.0.1, while the latest version available 
under Linux
appears to be 8.0.1 .

Falk

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




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