Re: Bash / cygwin process spawning (?) performance very slow

[litter]

> On 23/09/2015 17:17, lit...@null.net wrote:
 for a file of 167 lines. Process Explorer showed a CPU load of 20% on 
 bash.exe, which was almost completely Kernel time.
 Is such high Kernel load normal?
>>>
>>> may be. forks are time consuming and your command is spending all the
>>> time in fork
>>
>> So why is it spending all its time in fork? That is the question.
> 
> https://cygwin.com/faq.html#faq.api.fork

That doesn't answer my question on Kernel load. Why is it fast on your machine, 
and slow on mine?
How can I find the culprit?
 
>>
>>> In addition, I suspect your Antivirus is further slowing down the things.
>>
>> I don't run an Antivirus program
> 
> than some thing else is crashing your performance
> https://cygwin.com/faq/faq.html#faq.using.bloda

Obviously something is. The FAQ entry does not mention performance, but real 
failures.
How to further diagnose this?

Best regards,
Paul

--
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: Bash / cygwin process spawning (?) performance very slow

[Marco Atzeri]

On 24/09/2015 11:57, lit...@null.net wrote:

Obviously something is. The FAQ entry does not mention performance, but real 
failures.
How to further diagnose this?


together with the cygcheck output that I already mentioned
I suggest

1) to look on

  /proc/self/maps or /proc//maps

to looks for strange DLL loaded

2) try to use strace.
However usually strace impact the timing and the problem can never arise.



Best regards,
Paul


--
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: Issues encountered with new Cygwin version

[Andrey Repin]

Greetings, Linda Walsh!

>>> > > I believe the target of the symlink should be "protocol" (i.e.
>>> > > singular)
>>> >
>>> > Err. That is. How did no one found it earlier?
>>> ---
>>> Because it is plural on unix/linux?  MS seems to have misspelt it?
>> 
>> I believe it's "misspelt" due to the 8 character limit for legacy file
>> names,
> ---
> How would that affect 'services'?

It doesn't.


-- 
With best regards,
Andrey Repin
Thursday, September 24, 2015 13:29:32

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: Cygwin bash for loops : repeated errors : [main] bash 1972 fork: child -1 - CreateProcessW failed for errno 9 bash: fork: Bad file descriptor

[litter]

.> On 23/09/2015 17:03, lit...@null.net wrote:
>>> It seems a race problem, due to the repetitive fork of grep
>>> for every line of some-file
>>
>> So why does it fail? Seems like a bug to me!
>>
>> Regards,
>> Paul
> 
> As does not fail on my computer, I suspect is a race between your AV and 
> cygwin and sometimes cygwin wins.
> 
> 
> Regards
> Marco.

Good for you. I don't have AV SW as I mentioned. And even so, that still makes 
it a bug.

Anyhow, a suspicion is speculative. I thought this mailing list was meant to 
report issues, and I think this is an issue.
How can I further diagnose this? Is there a known way to further determine 
what's causing this?

Regards,
Paul

--
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: Cygwin bash for loops : repeated errors : [main] bash 1972 fork: child -1 - CreateProcessW failed for errno 9 bash: fork: Bad file descriptor

[Marco Atzeri]

On 24/09/2015 11:51, lit...@null.net wrote:

.> On 23/09/2015 17:03, lit...@null.net wrote:

It seems a race problem, due to the repetitive fork of grep
for every line of some-file


So why does it fail? Seems like a bug to me!

Regards,
Paul


As does not fail on my computer, I suspect is a race between your AV and
cygwin and sometimes cygwin wins.


Regards
Marco.


Good for you. I don't have AV SW as I mentioned. And even so, that still makes 
it a bug.


Your system timing performance as so poor that something
is likely interfering.
Don't assume that is a cygwin bug.


Anyhow, a suspicion is speculative. I thought this mailing list was meant to 
report issues, and I think this is an issue.


Yes, this is the right place.


How can I further diagnose this? Is there a known way to further determine 
what's causing this?


start with
> Problem reports:   http://cygwin.com/problems.html

"Run cygcheck -s -v -r > cygcheck.out and include that file as an 
attachment in your report. Please do not compress or otherwise encode 
the output. Just attach it as a straight text file so that it can be 
easily viewed. "


so we can look at your system configuration.


Regards,
Paul


Marco

--
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: Issues encountered with new Cygwin version

[Walter L.]

> > > > I believe the target of the symlink should be "protocol" (i.e.
> > > > singular)
> > >
> > > Err. That is. How did no one found it earlier?
> > ---
> > Because it is plural on unix/linux?  MS seems to have misspelt it?
>
> I believe it's "misspelt" due to the 8 character limit for legacy file
> names,
---
How would that affect 'services'?


Sorry, you lost me. 'services' has 8 characters in the file name and so is
its symlink target; That shouldn't be an issue. Of the 4 symlinks under
/etc/ (i.e. networks, hosts, services, and protocols), only 'protocols'
exceeds the 8 character limit and hence the actual target file in
Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the
*target* file not the symlinks themselves, which are fine.

~WL 



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

base-files-4.2-3 : attention maintainer

[Marco Atzeri]

On 23/09/2015 01:04, Walter L. wrote:

Hi,

I've just performed a fresh install of the latest (2.2.1) Cygwin on 64-bit 
Windows 7 and noticed 2 issues with the new version that I'd like to verify 
whether or not they are bugs:

1) The symlink to protocol file seems incorrect

[user@hostname /etc]$ ls -l | grep protocol
lrwxrwxrwx  1 user Domain Users 50 Sep 22 17:03 protocols -> 
/cygdrive/c/Windows/System32/drivers/etc/protocols
[user@hostname /etc]$ ls -l /cygdrive/c/Windows/System32/drivers/etc | grep 
protocol
-rwxrwx---+ 1 SYSTEM SYSTEM  1358 Jun 10  2009 protocol

I believe the target of the symlink should be "protocol" (i.e. singular)


Corinna,

the bug is in the
  /etc/postinstall/base-files-mketc.sh
of base-files-4.2-3


FILES="hosts protocols services networks"
OSNAME="$(/usr/bin/uname -s)"
WINETC="$(/usr/bin/cygpath -S -u)/drivers/etc"

[cut]

for mketc in ${FILES}
do
  if [ ! -e "/etc/${mketc}" -a ! -L "/etc/${mketc}" ]
  then
/usr/bin/ln -s -v "${WINETC}/${mketc}" "/etc/${mketc}"
  fi
done


As on my systems the bug is not present,
it can be a relative recent introduction.

Regards
Marco




--
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: workflow idiom to compare zip/tgz with folder subtree

[Warren Young]

On Sep 22, 2015, at 7:06 PM, Paul wrote:
> 
> Andrey Repin writes:
>> Git, Subversion... basically any sane VCS out there.
> 
> I've managed to avoid version control all these years
> because I wanted the convenience of bash file management and changing
> things on a whim as I see fit.

The only file management task that VCSes force you to do through the VCS is 
file moves/renames and deletions, and that’s only because a VCS can’t work out 
how to manage the files you told it to manage if there isn’t a file where you 
told it to expect one.  All changes to the file *content* can — and normally 
*are* — done outside the VCS.

Normally you check your changes into the VCS shortly after you make them and 
are happy with the changes, but it’s quite possible to put off check-ins for 
weeks or months.  I don’t do that at work on source code repositories, but I 
have one repo at home that backs up changes to things like ~/bin which 
sometimes lags way behind “current” like that.

That’s where the VCS’s diff command comes in handy.  It answers the question, 
“What did I change in this file 4 weeks ago?”

If you were using zip as the archiving format because you want a single file 
you can move between systems, I recommend that you look at Fossil, rather than 
the more popular VCSes:

   http://fossil-scm.org/

Fossil’s repository is a single well-strucured, compressed file, which makes it 
easy to back up, move to other machines, etc.  (It’s a SQLite database file, if 
that means anything to you.)

If you actually need ZIP files (or tarballs) for some reason, there is a Fossil 
command to get a particular point in history as an archive.

One of those points in history is called “tip”, meaning the state of the whole 
repository as of the most recent checkin, which means it’s a single command to 
get a zip file of all files at the tip of the Fossil repository.

Subversion is a bit simpler to use than Fossil, but its default storage format 
is a big pile o’ files, which means you pretty much need to do repository 
management through the svnadmin tool.

Git is even worse than svn in that the pile o’ files is in the same tree as the 
working file set, instead of a separate tree.

Git is also more complicated than Fossil:

   http://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

> And for lack of time to learn yet another system.

You should be able to get started with any sane VCS in maybe half an hour.  
Learning all the ins-and-outs will take time, but there’s power in mastering 
the details.

In terms of complexity, Subversion < Fossil < Git.

The only reason for someone with simple needs to go with Git is that you need 
the interoperability it provides, since it’s becoming the lingua franca of the 
developer world.  There’s something to be said for going with the standard, 
even if it’s a PITA in some ways.  

But I’m not telling a Windows user something they don’t already know with that, 
am I? :)
--
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: cygwin potentially corrupting permissions?

[Greg Freemyer]

Linda,

We seem to travel the same mailing lists.  This is my first time to cygwin's.

I saved your script as "lsacl.txt".  Then I used "cp lsacl.txt it" to
make a copy.

The copy is permission denied for reading.  Basic ls -l shows no
difference (as expected)

$ ls -l lsacl.sh it
rwx---+ 1 gaf None 1630 Sep 24 12:05 it
rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh

But your script does show a difference:

$ ./lsacl.sh lsacl.sh it
[u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh
[u::---,g::r-x,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it

My user id is "gaf".

fyi: I thought I knew how to read an ACL, but the above makes little
sense to me.  Note I can cat out "lsacl.sh", but I can't cat out "it".

Greg

--
Greg Freemyer
www.IntelligentAvatar.net


On Wed, Sep 23, 2015 at 10:58 PM, Linda Walsh  wrote:
> Greg Freemyer wrote:
>>
>> All,
>>
>> I've noticed on 2 different machines that if I copy (cp) a file I can
>> read with cygwin, I don't have permission to read the copy.
>
> ---
> What does the acl say?
>
> (Attached a script, lsacl, that I use -- it works
> with linux or cygwin and allows wildcards).
>
>
> #!/bin/bash
>
> ## $Id: lsacl,v 1.5 2015-08-02 10:29:25-07 law Exp law $
> # Version 2 -- try to work with getfacl on cygwin
> #
>
>
> shopt -s expand_aliases
> alias int=declare\ -i   sub=function  string=declare
>
> gfacl=$(type -P getfacl)
>
> if ! type -f cygwin 2>/dev/null ; then
> _un_=$(type -P uname)
> if  [[ $_un_ ]] ; then _os_=$($_un_ -o);
> elif[[ -e /proc/sys/kernel ]]; then _os_=Linux;
> else_os_=Cygwin;
> fi
> if  [[ $_os_ =~ Cygwin ]]; then function cygwin () {
> return 0; }
> elsefunction cygwin () { return 1; }
> fi
> unset _un_ _os_
> export -f cygwin
> fi
>
> if cygwin 2>/dev/null ;then
> [[ $gfacl ]] || { printf "FATAL: Cannot find getfacl in path\n";
> exit 1; }
> sub gfacl () { "$gfacl" "$@"; }
> else
> ## linux version has broken semantics requiring "-p"
> sub gfacl () { "$gfacl" -p "$@" ; }
> fi
>
> export -f gfacl
>
>
> sub facl2str {
> string fn=${1:?"Need pathname"}
> string s1='/^\#.*$/d; /^\s*$/d; s/\s*#.*$//;
> s/^(.)(ser|roup|ask|ther):/\1:/; y/\n/,/'
> string facl=$(gfacl -a "$fn"|sed -r "$s1"|tr "\n" ",")
> facl=${facl%,}
> string dacl=$(gfacl -d "$fn"|sed -r "s/^default://; $s1"|tr "\n"
> ",")
> dacl=${dacl%,}
> printf "[%s/%s]\n" "$facl" "$dacl"
> }
>
>
>
> int acllen=0 maxfnln=0
> #for fn in "$@" ; do if ((maxfnln<${#fn})); then maxfnln=${#fn}; fi ; done
>
> sub acl_str () {
> if cygwin ;then
> perm=$(facl2str "$fn")
> else
> qfn=$(printf "%q " "$fn")
> out="$(chacl -l "$fn")"
> perm="${out#$qfn}"
> fi
> printf "%s\n" "$perm"
> }
>
>
> for fn in "$@"; do
> int max=40
> perm=$(acl_str "$fn")
> int len=${#perm}
> if ((len>_acl_len_)); then acllen=len; fi
> if ((acllen>max));  then acllen=max; fi
> printf "%-${acllen}s %s\n" "$perm" "$fn"
> done
>

--
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: Bash / cygwin process spawning (?) performance very slow

[Lee]

On 9/24/15, litter wrote:
>> On 24/09/2015 11:57, litter wrote:
>>> Obviously something is. The FAQ entry does not mention performance, but
>>> real failures.
>>> How to further diagnose this?
>
> I took the plunge and spent almost a full day trying to find the cause.
... snip ...
> turns out that Comodo Firewall (Free version) loads a DLL in each process
> that is the cause of the delay.
... snip ...
> (although it would have been nice if there was an easier way to diagnose it,
> maybe with tracing?)

If you use http://www.dependencywalker.com/ on bash.exe with view/full
paths enabled, does the Comodo Firewall dll stand out or is it just
another .dll loaded from windows\system32?

Regards,
Lee

--
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: base-files-4.2-3 : attention maintainer

[Achim Gratz]

Marco Atzeri writes:
> the bug is in the
>   /etc/postinstall/base-files-mketc.sh
> of base-files-4.2-3
>
> 
> FILES="hosts protocols services networks"
> OSNAME="$(/usr/bin/uname -s)"
> WINETC="$(/usr/bin/cygpath -S -u)/drivers/etc"
>
> [cut]
>
> for mketc in ${FILES}
> do
>   if [ ! -e "/etc/${mketc}" -a ! -L "/etc/${mketc}" ]
>   then
> /usr/bin/ln -s -v "${WINETC}/${mketc}" "/etc/${mketc}"
>   fi
> done
> 
>
> As on my systems the bug is not present,
> it can be a relative recent introduction.

I've introduced this bug inadvertently when releasing base-files-4.1.
I'll fix it towards the weekend.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
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: Bash / cygwin process spawning (?) performance very slow

[Marco Atzeri]

On 24/09/2015 19:46, Lee wrote:

On 9/24/15, litter wrote:

On 24/09/2015 11:57, litter wrote:

Obviously something is. The FAQ entry does not mention performance, but
real failures.
How to further diagnose this?


I took the plunge and spent almost a full day trying to find the cause.

 ... snip ...

turns out that Comodo Firewall (Free version) loads a DLL in each process
that is the cause of the delay.

 ... snip ...

(although it would have been nice if there was an easier way to diagnose it,
maybe with tracing?)


Tracing may report it as at process load is reporting
the loaded dll's

--- Process 7380 loaded C:\Windows\System32\ntdll.dll at 7736
--- Process 7380 loaded C:\Windows\System32\kernel32.dll at 7724
--- Process 7380 loaded C:\Windows\System32\KernelBase.dll at 
07FEFDB2

--- Process 7380 loaded C:\Windows\System32\sysfer.dll at 74B4
--- Process 7380 loaded E:\cygwin64\bin\cygwin1.dll at 00018004
--- Process 7380 loaded E:\cygwin64\bin\cygiconv-2.dll at 0003C270
--- Process 7380 loaded E:\cygwin64\bin\cygintl-8.dll at 0003BEC9
--- Process 7380 loaded E:\cygwin64\bin\cygncursesw-10.dll at 
0003BD88

--- Process 7380 loaded E:\cygwin64\bin\cygreadline7.dll at 0003B5FD
--- Process 7380 loaded C:\Windows\System32\user32.dll at 76C6
--- Process 7380 loaded C:\Windows\System32\gdi32.dll at 07FEFEBE
--- Process 7380 loaded C:\Windows\System32\lpk.dll at 07FEFF3C
--- Process 7380 loaded C:\Windows\System32\usp10.dll at 07FEFF50
--- Process 7380 loaded C:\Windows\System32\msvcrt.dll at 07FEFF5D



If you use http://www.dependencywalker.com/ on bash.exe with view/full
paths enabled, does the Comodo Firewall dll stand out or is it just
another .dll loaded from windows\system32?


unlikely to appear as it is not a dependency but an injected dll



Regards,
Lee


--
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: Bash / cygwin process spawning (?) performance very slow

[litter]

> If you use http://www.dependencywalker.com/ on bash.exe with view/full
> paths enabled, does the Comodo Firewall dll stand out or is it just
> another .dll loaded from windows\system32?
> 
> Regards,
> Lee

I use Process Explorer to view in-process .dlls:

C:\WINDOWS\system32\guard32.dll

Regards,
Paul

--
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: cygwin potentially corrupting permissions?

[Linda Walsh]

Greg Freemyer wrote:


Totally logical, but not accurate. )

---
	What does it say if you do an 'lsacl' on "." 
(the parent directory).  


This is a local file system?  NTFS?
Do you have process hacker?  Maybe the writing process has a different
integrity label or such.

Process hacker lets you see what the integrity labels are on files,
but to see what they are on files you'd have to d/l another util.
(chml/regil



- cygwin is not properly maintaining the permissions when it manipulates a file


May not be able to ... Windows trumps cygwin.
MS-regularly screws w/windows, .. it's like switching to a new
init system every month... ok.. maybe not quite that bad...




Either way, I would really like a solution that doesn't involve a
manual chmod for every file I create via the normal Windows interface
and which I want to work with it in cygwin.

===
I can understand that -- that's sorta why I haven't upgraded
my cygwin lately -- She spent alot of time solving a problem that didn't
really appear on my system, so changing the whole security system -- well
I already know that cygwin doesn't respect existing standards or sources.
(overwrite windows mount points created -- and is shipping a login that
zeros your environment -- even when passed switch to not do so -- effectively
wipes your windows session -- forcing users to copy sessions from static
files to get around the problem.


--
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: How do I make my Emacs font match my xterm font?

[Jim Reisert AD1C]

I ended up downloading xlsfonts, and after a little trial-and-error,
this appears to be the matching font:

-misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1

So I have a new Emacs font, which for some reason seems smaller than
before, but it's certainly usable.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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: startx not working

[Marco Atzeri]

On 24/09/2015 20:56, Tim Higgins wrote:

When I run startx I get the following error.
higginst@HigginsT-LT-W7 ~
$ startx



same here, but have you tried startxwin ?

Regards
Marco



--
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: Bash / cygwin process spawning (?) performance very slow

[litter]

> Maybe:
> 
> strace bash -c 'time cat some-file | while read i;do echo 
> $i;/bin/true;done'
> 
> Haven't tested it.
> 
> Simplify the command:
> 
> for((i=0;i<150;i++));do /bin/true;done
> 
> to rule out a pipe-problem.

Thanks for the tips! Used a variant on the for loop to simplify the problem.

Regards,
Paul

--
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: Bash / cygwin process spawning (?) performance very slow

[Cliff Hones]

On 24/09/2015 18:24, lit...@null.net wrote:
>> On 24/09/2015 11:57, lit...@null.net wrote:
>>> Obviously something is. The FAQ entry does not mention performance, but 
>>> real failures.
>>> How to further diagnose this?
> 
> I took the plunge and spent almost a full day trying to find the cause.
> 
> 1. Booting into Safe Mode gave a huge performance boost
> 2. By eliminating all services and programs in Normal Mode, one-by-one, I 
> found the offender:
> 
> turns out that Comodo Firewall (Free version) loads a DLL in each process 
> that is the cause of the delay.
> Although I only use the Firewall, and do not use any "AntiVirus" features, 
> still it causes delay during startup of a process.
> 
> However, after disabling it -- which did speed up process spawning in Bash -- 
>  I encountered the other problem I already had much more often.
> For now I consider the issue of slow spawning to be solved
> (although it would have been nice if there was an easier way to diagnose it, 
> maybe with tracing?)

Comodo firewall pro is listed in 
https://cygwin.com/faq/faq.html#faq.using.bloda.
Looks as if the free version should be listed too.


--
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: Issues encountered with new Cygwin version

[Andrey Repin]

Greetings, Linda Walsh!

>>> > > > > I believe the target of the symlink should be "protocol" (i.e.

>>> How would that affect 'services'?
>> 
>> Sorry, you lost me. 'services' has 8 characters in the file name and so is
>> its symlink target; That shouldn't be an issue. Of the 4 symlinks under
>> /etc/ (i.e. networks, hosts, services, and protocols), only 'protocols'
>> exceeds the 8 character limit and hence the actual target file in
>> Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the
>> *target* file not the symlinks themselves, which are fine.
> ---

> Oops.. my bad -- don't know why I substituted services. However,
> weren't those files there for unix-subsystem support?  Not sure:

> From this:

> https://books.google.com/books?id=6hlNFc7drzEC=PA39=PA39=reason+for+drivers/etc/protocol+on+windows=bl=en=X=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false#v=snippet=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false
> (page 39) -- it says those files were specific to NT systems beginning with
> NT4.0, which used NTFS.  I don't know if NT supported having the 
> windows/system32
> directory on FAT][32]...

It did.
Read the help article about "convert" tool for more info.

> NT4 would have been the version before Windows 2000

Aye.


-- 
With best regards,
Andrey Repin
Thursday, September 24, 2015 21:32:08

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: startx not working

[Marco Atzeri]

Please leave the mailing list in copy

On 24/09/2015 21:48, Tim Higgins wrote:

Yes I get a different error

Just trying to get X working on my desktop as I need its functionality
for some Unix jobs that require X.

Tim Higgins



As openGL crashed and the suggestion on the screenshot is "-nowgl"

can you try

startxwin -- -multiwindow +iglx -nowgl

it should disable the hardware acceleration.

http://x.cygwin.com/docs/ug/using-glx.html

Regards
Marco

--
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: cygwin potentially corrupting permissions?

[Andrey Repin]

Greetings, Greg Freemyer!

> We seem to travel the same mailing lists.  This is my first time to cygwin's.

> I saved your script as "lsacl.txt".  Then I used "cp lsacl.txt it" to
> make a copy.

> The copy is permission denied for reading.  Basic ls -l shows no
> difference (as expected)

> $ ls -l lsacl.sh it
> rwx---+ 1 gaf None 1630 Sep 24 12:05 it
> rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh

Notice the "+" at the end of basic POSIX access bits.
And use getfacl (or native icacl(s)) to view real permissions.

> But your script does show a difference:

> $ ./lsacl.sh lsacl.sh it
> [u::---,g::---,g:root:rwx,g:Authenticated 
> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh
> [u::---,g::r-x,g:root:rwx,g:Authenticated 
> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it

> My user id is "gaf".

> fyi: I thought I knew how to read an ACL, but the above makes little
> sense to me.  Note I can cat out "lsacl.sh", but I can't cat out "it".

Your system seems to be mangled. There should be no "root" user.

Also, please avoid top posting as per list rules.


-- 
With best regards,
Andrey Repin
Thursday, September 24, 2015 21:35:24

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: cygwin potentially corrupting permissions?

[Linda Walsh]

Andrey Repin wrote: 

Your system seems to be mangled. There should be no "root" user.

Also, please avoid top posting as per list rules.


You are missing one?  Don't tell me, you have
Administrator instead?

Maybe that's why you see Greg's messages as top-posted, where
as I saw him as interleaving his response w/what I said? ;-)

If you have Win7-Pro or above, you can rename Admin
and Guest accounts -- which is recommended for security reasons.

If you read windows 'rules', you'd know that... (so many rules
to read...really hard for someone to keep up)...

*cheers*
-l

--
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: Bash / cygwin process spawning (?) performance very slow

[litter]

> On 24/09/2015 11:57, lit...@null.net wrote:
>> Obviously something is. The FAQ entry does not mention performance, but real 
>> failures.
>> How to further diagnose this?

I took the plunge and spent almost a full day trying to find the cause.

1. Booting into Safe Mode gave a huge performance boost
2. By eliminating all services and programs in Normal Mode, one-by-one, I found 
the offender:

turns out that Comodo Firewall (Free version) loads a DLL in each process that 
is the cause of the delay.
Although I only use the Firewall, and do not use any "AntiVirus" features, 
still it causes delay during startup of a process.

However, after disabling it -- which did speed up process spawning in Bash --  
I encountered the other problem I already had much more often.
For now I consider the issue of slow spawning to be solved
(although it would have been nice if there was an easier way to diagnose it, 
maybe with tracing?)

Regards,
Paul

--
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: cygwin potentially corrupting permissions?

[Greg Freemyer]

On Thu, Sep 24, 2015 at 2:06 PM, Linda Walsh  wrote:
> Greg Freemyer wrote:
>>
>> Linda,
>
>
>> I saved your script as "lsacl.txt".  Then I used "cp lsacl.txt it" to
>> make a copy.
>>
>> The copy is permission denied for reading.  Basic ls -l shows no
>> difference (as expected)
>>
>> $ ls -l lsacl.sh it
>> rwx---+ 1 gaf None 1630 Sep 24 12:05 it
>> rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh
>>
>> But your script does show a difference:
>>
>> $ ./lsacl.sh lsacl.sh it
>> [u::---,g::---,g:root:rwx,g:Authenticated
>> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh
>> [u::---,g::r-x,g:root:rwx,g:Authenticated
>> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it
>
> ---
> Well user 'gaf' (that's you, from the file perms has no access).
>
> So up front, you are denied before anything happens.

Totally logical, but not accurate. )

I am the owner of both "it" and "lsacl.sh."

For both the user permissions are "---"  (why I don't know.  I created
lsacl.sh by a simple drag and drop out of firefox.)

I can cat out "lsacl.sh", but not "it".

I know "chmod +rw it" gives me access to the file.  The problem is
Windows is creating files with permissions like lsacl.sh routinely on
my system.

Then when I do anything to them in cygwin, the permissions are
modified to block my access.

I first noticed this because I was exporting CSV files from excel,
then editing them with vi from cygwin.

On the first edit, all was good.  After that, I no longer had
permission to access the file.

So, either:

- Windows 7 (on 2 different machines) has started using default
permissions that are bad on their face

- cygwin is not properly maintaining the permissions when it manipulates a file

Either way, I would really like a solution that doesn't involve a
manual chmod for every file I create via the normal Windows interface
and which I want to work with it in cygwin.

Greg


> lsacl is the embedded acl (the '+') at the end of the file perms
>
> u::--- =  user seen by 'ls -l' has no access, g::--- =  group seen by 'ls -l
> has no access
> g:root:rwx = group root has read/write/execute access
> g:Authenticated Users:rwx == group consisting of Authenticated Users...
> (after you login or provide credentials).
> m:rwx  m = a maximum allowed privs 'mask' for user/groups other
> than owner, but since all bits are turned on, it has no limiting
> effect
> o:---  = other has no access
>
> So the main take-away is that since your 'user' has no access, pretty much
> everything else is ignored.
>
> From the mode-bits+acl, amost anyone in the groups:
> root, Authenticated Users,SYSTEM, or Users, ***except** User 'gaf' (you)
> should have access...
>
> you might try 1) chmod u+rwx file ...
> then look at both mode+acl... if you have no access
> and acl still says u::---, then nuke the acl or modify it with "setfacl"
> (setfacl --help)...
>
>>
>> We seem to travel the same mailing lists.  This is my first time to
>> cygwin's.
>>
> 
> Yeah... I wondered about that -- my Tbird tried to change my
> reply addr to suse(at)tlinx based on you being the 1st address I typed
> in... ;-)

--
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: bash-4.3.33-1 fails to execute shell script with CR+LF EOL in text-mounted directory

[Eric Blake]

On 03/26/2015 09:37 AM, sm...@cygwin.akamoz.jp wrote:
> Dear Cygwin developers:
> 
>  It seems that bash-4.3.33(1) handles CR+LF end-of-line in 
> the shell-script incorrectly, all of the following conditions are met:
> 
> a. the shell-script file is on TEXT-MOUNTED directory,
> b. end-of-line style of the file is CR+LF, and
> c. the command in the file includes & (exec-background),
>$( ), or `` (command substitutions)
> 
> It works:
> d. it is on the binary-mounted directory, and with igncr shell-option,
> e. end-of-line style is LF, or
> f. condition c is not met. It seems that &&, | and || work fine,
>although I didn't try all of the metachacters and control-constructs.
> 

Please try the (currently-experimental) 4.3.42-4, which should fix the
issues observed.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[newlib-cygwin] Created tag newlib-snapshot-20150924

[Jeff Johnston]

The unsigned tag 'newlib-snapshot-20150924' was created pointing to:

 f296bb3... Minimize newlib code size for ft32

Tagger: Jeff Johnston <jjohn...@redhat.com>
Date: Thu Sep 24 16:16:18 2015 -0400

Snapshot for 09/24.

Advices on compiling a C, C++, python and fortran code...

[Pierre Juillard]

Hi,

I have found different emails related to compiling while linking
libraries in a Cygwin environment.

These mails are quite old (usually from year 2000 to 2003) and explain
how linking either libpthread.a or libdl.a with the program being
compiled.
Manipulations indicated mention the need to create symbolic links to
link to either cygwin1.dll or libcygwin, or to use specific
compilation flags.


Please, could someone tell me if such manipulations are still required
to be able to compile Code_Aster in latest cygwin environment (I am
using 2.2.1)?

Most notably, this code is written Fortran90 + C + C++.
Its compilation is managed by a quite complex python script that has
been written to work on Linux workstations (Debian, Ubuntu...).

The python script checks before compilation that the following
libraries are found in the system:
- libpthread.so or libpthread.a
- libdl.so or libdl.a
- libutil.so or libutil.a
- libm.so or libm.a

I confirm that the python script correctly found in the cygwin lib
directory the following ones:
 libpthread.a
 libdl.a
 libutil.a
 libm.a

Please, do I have with current cygwin version to use specific flags or
to create specific symlink to make sure the code get correctly linked
against these libraries?
Also, once the executable will be obtained, and if I want to copy it
on another Windws machine without Cygwin environment, do I have to
make sure to copy as well cygwin1.dll library? If so, in which
directory can I put it?

I thank you in advance for your help.
Best regards,

Pierre

--
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: startx not working

[Marco Atzeri]

On 24/09/2015 22:19, Tim Higgins wrote:

I can get an x window when I enter startx -d but it does not seem to display 
the x programs that I am running on my UNIX server.



http://x.cygwin.com/docs/ug/using-remote-apps.html

"Note: You must provide the -listen tcp option to startx or startxwin so 
that the X server will listen for TCP/IP connections. (See this FAQ for 
more details). "




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

[ANNOUNCEMENT] Updated: bash-4.3.42-4

[Eric Blake (cygwin)]

A new release of bash, 4.3.42-4, has been uploaded and will soon reach a
mirror near you.  It is currently marked experimental pending test
results from others that have reported problems on text mounts:
https://cygwin.com/ml/cygwin/2015-03/msg00496.html
https://cygwin.com/ml/cygwin/2015-06/msg00087.html

But assuming it passes those tests, it will be promoted to current,
leaving 4.3.42-3 as the previous version.

NEWS:
=
This is a minor build that fixes an upstream typo that broke bash
behavior when reading scripts from a text mount, regardless of whether
you used the igncr option.  Thanks to Jeff Downs for helping isolate the
problem.

This build of bash is immune to the ShellShock vulnerabilities (although
unpatched bash 4.3 is vulnerable, the official upstream patches solve
the issue).  By now, you should no longer be running a vulnerable bash,
but to double check you can run the following test to make sure you are
not subject to arbitrary remote code execution due to ShellShock:
$ env 'bad=() { echo vulnerable; }' bash -c bad

If it prints "bash: bad: command not found", your version of bash is
safe and not subject to remote exploits.  If it prints "vulnerable", you
need to upgrade now.

There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by
default.
2. d2u is your friend.  You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file.  If you
absolutely must use files with \r\n line endings, consider mounting the
directory where those files live as a text mount.  However, text mounts
are not as well tested or supported on the cygwin mailing list, so you
may encounter other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific set option, named "igncr",
to force bash to ignore \r, independently of cygwin's mount style.  As
of bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files.  I hope to convince the upstream bash maintainer to
accept this patch into a future bash release even on Linux, rather than
keeping it a cygwin-specific patch, but only time will tell.  There are
several ways to activate this option:
4a. For a single affected script, add this line just after the she-bang:
 (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the option, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired.  Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it.  It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks
the current state of 'set -o igncr'.  If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make
sense to support the option through both set and shopt, and SHELLOPTS
proved to be more powerful.
5. You can also experiment with the IFS variable for controlling how
bash will treat \r during variable expansion.
6. There are varying levels of speed at which bash operates.  The
fastest is on a binary mount with igncr disabled (the default behavior).
 Next would be text mounts with igncr disabled and no \r in the
underlying file. Next would be binary mounts with igncr enabled.  And
the slowest that bash will operate is on text mounts with igncr enabled.
7. As additional cygwin extensions, this version of bash includes:
7a. EXECIGNORE - a colon-separated list of glob patterns to ignore
when completing on executables.  EXECIGNORE=*.dll is common.
7b. completion_strip_exe - using 'shopt -s completion_strip_exe'
makes completion strip .exe suffixes
8. This version of bash is immune to ShellShock (CVE-2014-6271 and
friends) because it exports functions via 'BASH_FUNC_foo%%=' rather than
'foo=' environment variables.  However, doing this has exposed
weaknesses in some other utilities like 'ksh' or 'at' that fail to scrub
their environment to exclude what is not a valid name for them.
9. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas.  This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
Thanks to Dan Colascione for providing the EXECIGNORE 

Re: workflow idiom to compare zip/tgz with folder subtree

[Andrey Repin]

Greetings, Paul!

> I noticed that fossil & cvs are part of cygwin.  I will have to bite
> the bullet & try a few baby steps at some point.

If anything, I would NOT recommend CVS to anyone making their first steps into
VCS world.
Subversion is way more consistent, better thought out and have about the same
usability characteristics where they are comparable. (And don't forget the
marvelous svnbook.org ...)
The unly reason I was using CVS up until a month ago for some of my projects
is because I was lazy and did not convert them to Subversion ten years ago.


-- 
With best regards,
Andrey Repin
Friday, September 25, 2015 04:36:25

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: cygwin potentially corrupting permissions?

[Andrey Repin]

Greetings, Linda Walsh!

> Andrey Repin wrote: 
>> Your system seems to be mangled. There should be no "root" user.
>> 
>> Also, please avoid top posting as per list rules.
> 
> You are missing one?  Don't tell me, you have
> Administrator instead?

No, I have my own account, that's quite enough.

> Maybe that's why you see Greg's messages as top-posted, where
> as I saw him as interleaving his response w/what I said? ;-)

> If you have Win7-Pro or above, you can rename Admin
> and Guest accounts --

You can rename them in NT4, too. Just sayin'.

> which is recommended for security reasons.

Obscurity has no relation to security.
Oh, and these both are disabled on my systems.

> If you read windows 'rules', you'd know that... (so many rules
> to read...really hard for someone to keep up)...

There's no such rules as "rename default accounts".
It makes no sense and bears no reason.


-- 
With best regards,
Andrey Repin
Friday, September 25, 2015 04:43:28

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: cygwin potentially corrupting permissions?

[Greg Freemyer]

On Thu, Sep 24, 2015 at 3:22 PM, Ken Brown  wrote:

>
>
> The problem could be caused by the default ACL on whatever directory you're
> working in.  You might consider running 'setfacl -b' and/or 'setfacl -k' on
> that directory.  (Run 'setfacl --help' for more information.)


I just posted this, but it looks like directories created in cygwin
have reasonable ACLs, but directories created via "File Explorer" are
bizarre.

Where bizzare is defined as:
$ getfacl /cygdrive/c/Test-dir-created-in-file-explorer/
# file: /cygdrive/c/Test-dir-created-in-file-explorer/
# owner: GAF
# group: None
user::---
group::---
group:root:rwx
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Users:r-x
mask:rwx
other:---
default:user::---
default:group::---
default:group:root:rwx
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Users:r-x
default:mask:rwx
default:other:---

Here's getfacl for C:\

$ getfacl /cygdrive/c
# file: /cygdrive/c
# owner: TrustedInstaller
# group: TrustedInstaller
user::---
group::---
group:root:rwx
group:Authenticated Users:---
group:SYSTEM:rwx
group:Users:r-x
mask:rwx
other:---
default:user::---
default:group::---
default:group:root:rwx
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Users:r-x
default:mask:rwx
default:other:---

Is that what others have?

fyi: I just realized I installed "System Mechanic" around the time I
started seeing problems.  It is installed on both of the machines
having issues.  I wonder if it adulterated my ACLs in an attempt to
make my machine safer?

Thanks
Greg

--
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: cygwin potentially corrupting permissions?

[Greg Freemyer]

On Thu, Sep 24, 2015 at 9:46 PM, Andrey Repin  wrote:
> Obscurity has no relation to security

Tell any Army in the world about that theory.  They should save their
money wasted on camouflage, stealth technology, etc.

But, I did not knowingly add the "root" group.

Greg

--
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: cygwin potentially corrupting permissions?

[Linda Walsh]

Andrey Repin wrote:

Obscurity has no relation to security.
Oh, and these both are disabled on my systems.


If you read windows 'rules', you'd know that... (so many rules
to read...really hard for someone to keep up)...


There's no such rules as "rename default accounts".
It makes no sense and bears no reason.

---
Security best practices :

See "https://technet.microsoft.com/en-us/library/cc747353%28v=ws.10%29.aspx;
and "https://technet.microsoft.com/en-us/library/jj852273.aspx;


--
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: cygwin potentially corrupting permissions?

[Linda Walsh]

Greg Freemyer wrote:

On Thu, Sep 24, 2015 at 3:27 PM, Linda Walsh  wrote:

Greg Freemyer wrote:


Totally logical, but not accurate. )

---
What does it say if you do an 'lsacl' on "." (the parent directory).


$ ./lsacl.sh .
[u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] .

But maybe this is interesting.  I just created 2 folders in C:\   .  I
did it at the C:\ level because I can't imagine I ever modified the
ACLs on C:\.

Anyway, one directory was created via "mkdir" in cygwin.  The other
via the file explorer.  Look at how different the ACLs are:

$ mkdir /cygdrive/c/Test-dir-created-in-cygwin

$ ./lsacl.sh /cygdrive/c/Test-dir-created-in-cygwin/
[u::rwx,g::r-x,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x/u::rwx,g::r-x,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x]
/cygdrive/c/Test-dir-created-in-cygwin/

$ ./lsacl.sh /cygdrive/c/Test-dir-created-in-file-explorer/
[u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---]
/cygdrive/c/Test-dir-created-in-file-explorer/

What's that about?  Again I'm not expert at ACLs, but the ACLs on the
directory created via File Explorer look really strange to me.

-
	That looks like the 'Creator User & Creator Group Policies at work, 
which try to let you create a dir in root, but give limited access to

that dir -- but doesn't allow just any Creator to have full access...

I think you are seeing a trickle down effect from the creator owner policy 
and the creator group policy banning full access -- because if you look

at the security tab in explorer I'll be those are pretty restricted...





This is a local file system?  NTFS?


Yes, C: drive. It's my local system drive on both computers and NTFS
on both machines.


Do you have process hacker?  Maybe the writing process has a different
integrity label or such.


Look at the acl in the Explorer 'security tab'  You find some extra
rules for 'creators' that are supposed to allow them to do things inside the dir
but not to the dir or some such.




No, but let me know if you still want me to pursue that.  For now I'm
thinking the ACLs on folders created via File Explorer are somehow
getting screwed up.


'screwed-up' is relative -- i.e. in this case, likely what explorer
is designed to do, (screw you), *str8-face*...

In the home directory you want to deal with this in (I wouldn't
suggest changing drives from root folder (I do such things and constantly end
up with 'shot-in-foot' type problems that I get to have 'fun' fixing! ;->)
But get rid of the creator rules so they won't propagate have to do it from
windows those because those entities aren't posix.


--
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: cygwin potentially corrupting permissions?

[Greg Freemyer]

On Thu, Sep 24, 2015 at 2:37 PM, Andrey Repin  wrote:
> Greetings, Greg Freemyer!
>
>> We seem to travel the same mailing lists.  This is my first time to cygwin's.
>
>> I saved your script as "lsacl.txt".  Then I used "cp lsacl.txt it" to
>> make a copy.
>
>> The copy is permission denied for reading.  Basic ls -l shows no
>> difference (as expected)
>
>> $ ls -l lsacl.sh it
>> rwx---+ 1 gaf None 1630 Sep 24 12:05 it
>> rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh
>
> Notice the "+" at the end of basic POSIX access bits.
> And use getfacl (or native icacl(s)) to view real permissions.

I'm using Linda' script that does that, but here's the raw getfacl
output for 2 folders created in C:\Note they have very different
ACLs.  Why?

$ getfacl /cygdrive/c/Test-dir-created-in-cygwin/
# file: /cygdrive/c/Test-dir-created-in-cygwin/
# owner: GAF
# group: None
user::rwx
group::r-x
group:root:rwx
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Users:r-x
mask:rwx
other:r-x
default:user::rwx
default:group::r-x
default:group:root:rwx
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Users:r-x
default:mask:rwx
default:other:r-x



$ getfacl /cygdrive/c/Test-dir-created-in-file-explorer/
# file: /cygdrive/c/Test-dir-created-in-file-explorer/
# owner: GAF
# group: None
user::---
group::---
group:root:rwx
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Users:r-x
mask:rwx
other:---
default:user::---
default:group::---
default:group:root:rwx
default:group:Authenticated Users:rwx
default:group:SYSTEM:rwx
default:group:Users:r-x
default:mask:rwx
default:other:---

That last one with the directory created via file explorer has truly
bizarre (to me) ACLs.  Normal?  If not, how do I fix it.

Note I have 2 different Win 7 boxes showing this same behavior.

>
>> But your script does show a difference:
>
>> $ ./lsacl.sh lsacl.sh it
>> [u::---,g::---,g:root:rwx,g:Authenticated 
>> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh
>> [u::---,g::r-x,g:root:rwx,g:Authenticated 
>> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it
>
>> My user id is "gaf".
>
>> fyi: I thought I knew how to read an ACL, but the above makes little
>> sense to me.  Note I can cat out "lsacl.sh", but I can't cat out "it".
>
> Your system seems to be mangled. There should be no "root" user.

hmm. I think that is a "root" group, not a "root" user.

I seriously doubt I created a root as a group.  Are you sure that
isn't standard with cygwin?

note: I love using cygwin, but I'm not very knowledgeable about user
and group management in cygwin.  On the other hand, I'm pretty good at
it in Linux. (I'm a 30+ year UNIX/Linux user)

> Also, please avoid top posting as per list rules.

If I did, I will try to avoid it in the future.  This e-mail is
interspersed.  I assume that is desired.

Greg

--
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: Issues encountered with new Cygwin version

[Linda Walsh]

Walter L. wrote:

> > > > I believe the target of the symlink should be "protocol" (i.e.



How would that affect 'services'?


Sorry, you lost me. 'services' has 8 characters in the file name and so is
its symlink target; That shouldn't be an issue. Of the 4 symlinks under
/etc/ (i.e. networks, hosts, services, and protocols), only 'protocols'
exceeds the 8 character limit and hence the actual target file in
Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the
*target* file not the symlinks themselves, which are fine.

---

Oops.. my bad -- don't know why I substituted services. However,
weren't those files there for unix-subsystem support?  Not sure:


From this:


https://books.google.com/books?id=6hlNFc7drzEC=PA39=PA39=reason+for+drivers/etc/protocol+on+windows=bl=en=X=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false#v=snippet=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false
(page 39) -- it says those files were specific to NT systems beginning with
NT4.0, which used NTFS.  I don't know if NT supported having the 
windows/system32
directory on FAT][32]...  NT4 would have been the version before Windows 2000



--
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: [Bug] bash' read builtin command behaves differently on '\r' (4.3.33)

[Eric Blake]

On 05/14/2015 01:32 PM, Mikhail Usenko wrote:
> 
> Cygwin version: 2.0.2-1
> 
> [linux]$ bash --version
>   GNU bash, version 4.3.33(1)-release (i686-redhat-linux-gnu)
> [cygwin]$ bash --version
>   GNU bash, version 4.3.33(1)-release (x86_64-unknown-cygwin)
> 
> Testcase:
> [linux]$ echo -ne "\r\n" | { read t; echo "$t"; } | od -A n -t x1
>   0d 0a
> [cygwin]$ echo -ne "\r\n" | { read t; echo "$t"; } | od -A n -t x1
>   0a
> 
> But then, the pipe itself is OK:
> [cygwin]$ echo -e "\r" | od -A n -t x1
>   0d 0a

Jeff Downs helped me investigate off-list, and I think he found the
culprit (a typo in input.c that requested O_TEXT when it meant B_TEXT,
when mapping from open() flags to bash's internal B_* flags). I'm
building a new bash build right now, and will shortly be posting it for
testing.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

How do I make my Emacs font match my xterm font?

[Jim Reisert AD1C]

After the recent fonts reorganization, the font I (used to ) specify
for Emacs in my ~/.Xresources file no longer works:

Font `-adobe-courier-medium-r-*-*-*-96-*-*-*-*-iso8859-1' is not defined

Emacs will work if I comment out the font, albeit with a different
font and character size.  My xterm font seems unchanged.

Ideally, what I would like is for my Emacs font to exactly match my
xterm font.  How can I go about doing this?

Thanks - Jim

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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: How do I make my Emacs font match my xterm font?

[Ken Brown]

On 9/24/2015 1:16 PM, Jim Reisert AD1C wrote:

After the recent fonts reorganization, the font I (used to ) specify
for Emacs in my ~/.Xresources file no longer works:

 Font `-adobe-courier-medium-r-*-*-*-96-*-*-*-*-iso8859-1' is not defined


I'm not positive, but I think you might need to install 
xorg-x11-fonts-Type1.


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: cygwin potentially corrupting permissions?

[Linda Walsh]

Greg Freemyer wrote:

Linda,



I saved your script as "lsacl.txt".  Then I used "cp lsacl.txt it" to
make a copy.

The copy is permission denied for reading.  Basic ls -l shows no
difference (as expected)

$ ls -l lsacl.sh it
rwx---+ 1 gaf None 1630 Sep 24 12:05 it
rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh

But your script does show a difference:

$ ./lsacl.sh lsacl.sh it
[u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh
[u::---,g::r-x,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it

---
Well user 'gaf' (that's you, from the file perms has no access).

So up front, you are denied before anything happens.

lsacl is the embedded acl (the '+') at the end of the file perms

u::--- =  user seen by 'ls -l' has no access, 
g::--- =  group seen by 'ls -l has no access

g:root:rwx = group root has read/write/execute access
g:Authenticated Users:rwx == group consisting of Authenticated Users...
(after you login or provide credentials).
m:rwx  m = a maximum allowed privs 'mask' for user/groups other
than owner, but since all bits are turned on, it has no limiting
effect
o:---  = other has no access

So the main take-away is that since your 'user' has no 
access, pretty much everything else is ignored.



From the mode-bits+acl, amost anyone in the groups:
root, Authenticated Users,SYSTEM, or Users, 
***except** User 'gaf' (you) should have access...


you might try 
1) chmod u+rwx file ... 


then look at both mode+acl... if you have no access
and acl still says u::---, then nuke the acl 
or modify it with "setfacl" (setfacl --help)...




We seem to travel the same mailing lists.  This is my first time to cygwin's.



Yeah... I wondered about that -- my Tbird tried to change my
reply addr to suse(at)tlinx based on you being the 1st address I typed
in... ;-)

--
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: How do I make my Emacs font match my xterm font?

[Jim Reisert AD1C]

On Thu, Sep 24, 2015 at 11:50 AM, Ken Brown wrote:

> I'm not positive, but I think you might need to install xorg-x11-fonts-Type1.

Thanks, Ken.  I tried, but it did not fix the problem.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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: cygwin potentially corrupting permissions?

[Ken Brown]

On 9/24/2015 2:52 PM, Greg Freemyer wrote:

On Thu, Sep 24, 2015 at 2:06 PM, Linda Walsh  wrote:

Greg Freemyer wrote:


Linda,




I saved your script as "lsacl.txt".  Then I used "cp lsacl.txt it" to
make a copy.

The copy is permission denied for reading.  Basic ls -l shows no
difference (as expected)

$ ls -l lsacl.sh it
rwx---+ 1 gaf None 1630 Sep 24 12:05 it
rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh

But your script does show a difference:

$ ./lsacl.sh lsacl.sh it
[u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh
[u::---,g::r-x,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it


---
 Well user 'gaf' (that's you, from the file perms has no access).

 So up front, you are denied before anything happens.


Totally logical, but not accurate. )

I am the owner of both "it" and "lsacl.sh."

For both the user permissions are "---"  (why I don't know.  I created
lsacl.sh by a simple drag and drop out of firefox.)

I can cat out "lsacl.sh", but not "it".

I know "chmod +rw it" gives me access to the file.  The problem is
Windows is creating files with permissions like lsacl.sh routinely on
my system.

Then when I do anything to them in cygwin, the permissions are
modified to block my access.

I first noticed this because I was exporting CSV files from excel,
then editing them with vi from cygwin.

On the first edit, all was good.  After that, I no longer had
permission to access the file.

So, either:

- Windows 7 (on 2 different machines) has started using default
permissions that are bad on their face

- cygwin is not properly maintaining the permissions when it manipulates a file

Either way, I would really like a solution that doesn't involve a
manual chmod for every file I create via the normal Windows interface
and which I want to work with it in cygwin.


The problem could be caused by the default ACL on whatever directory 
you're working in.  You might consider running 'setfacl -b' and/or 
'setfacl -k' on that directory.  (Run 'setfacl --help' for more 
information.)


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: workflow idiom to compare zip/tgz with folder subtree

[Paul]

Eliot Moss wrote:
> There are also various backup tools based on rsync and compression.
> One of these is called duplicity, and it supports encryption as
> well.  But I suspect there are a number of these and that you can
> find one that matches your task ...

Andrey Repin wrote:
> It seems he need comparison over reservation.  I don't know of any
> backup tools that offer differential view against backup content.
> Not that I know many backup tools, though...

Warren Young suggested: fossil

Thank you all.  I've perused and pondered.  There is a key constraint
that I neglected to mention.  I am shuttling incremental work back and
forth between two locations using disc.  At one of the sites, the only
possible tools are M$ Office and a snapshot of Cygwin.  The full copy
of the working hierarchy exists at the two sites (almost identical).
The more restrictive site is the authoritative home of the historical
snapshots, though I may have mini-snapshots at the alternative site.
The comparison of the working file hierarchy with snapshots lets me
vet what needs to be shuttle back and forth; the majority of the
differences will not be relevant as the hierarcy exists at both sites.
I use the same archival scheme for local snapshots and for shuttling
work between sites, though the content is not the same (I won't take
an entire local snapshot with me on disc most of the time).

Most of the files are not software, though parallels can be drawn:
Long SQL scripts, Matlab scripts, images, data files, VBA, Matlab
files, text files, LaTeX files, image files, and M$ Office files
(Access, Excel, Word, Powerpoint, PST).  This is not a development
environment, it is an analysis environment (with code hackery to that
end).  However, the evolution of files and version control
requirements probably overlap (I can only guess as I've never worked
in a regulated code development environment, relying instead on my own
adhoc snapshots & incrementals).  One differences from the days when I
wrote "real" (compiled) code is that I'm not just archiving source
code; some of the files are images, databases, etc., and take up a lot
of space.  I end up creating incrementals a lot more, or simply
leaving the big files out of the snapshot routine (relying on very old
snapshots).  My analysis strategy is strongly influenced by this; I
try to avoid computational approaches that rely on intermediately
generated data that need to be archvied.  As much as possible,
everything should be quickly generatable from raw client input data
files.  Been able to get away with that so far, with a great deal of
effort.

I rely alot on bash hackery, even though I'm no graybeard.  "find",
"diff -qr", and "xargs" are indispensible, and using vim window
splitting, it is very efficient to browse the diff output and warp to
discrepant text files, and even delve into zip files to open its
content, and then use vimdiff to cruise the discrepancies.  The
synergy between vim & bash are (to me) like magic, scripting up copies
and such and piping them to bash.  For the most part, however, you
need to unpack the snapshot (or rebuild it from incrementals).  Andrey
is right, the main thing causing me to put the question out there is
the desire to avoid this.

I noticed that fossil & cvs are part of cygwin.  I will have to bite
the bullet & try a few baby steps at some point.


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

Solved Re: Bash / cygwin process spawning (?) performance very slow

[litter]

> turns out that Comodo Firewall (Free version) loads a DLL in each process 
> that is the cause of the delay.
> Although I only use the Firewall, and do not use any "AntiVirus" features, 
> still it causes delay during startup of a process.
> 
> However, after disabling it -- which did speed up process spawning in Bash -- 
>  I encountered the other problem I already had much more often.
> For now I consider the issue of slow spawning to be solved
> (although it would have been nice if there was an easier way to diagnose it, 
> maybe with tracing?)

After some more experimenting, and reading on Comodo issues in combination with 
Chrome, I found the following solution:
Add the cygwin installation folder to Comodo's 'Detect Shellcode Injections 
Exclusions' setting. This will lead to an immediate drop
in 'spawn' times to more acceptable levels. Somehow 'Detect Shellcode 
Injections' is active, even when HIPS is disabled.

Paul


--
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] Updated: bash-4.3.39-2

[Eric Blake]

On 06/04/2015 03:51 AM, Mikhail Usenko wrote:
> Eric Blake (cygwin) <...> wrote:
>> 4.3.39-2
> 
> Hello, Eric.
> It has the same issue as in the previous version:
> eating one \r from the odd numbered chains of the \r.
> 

Please try the (currently-experimental) 4.3.42-4, which should fix the
issues observed.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Updated: bash-4.3.42-4

[Eric Blake (cygwin)]

A new release of bash, 4.3.42-4, has been uploaded and will soon reach a
mirror near you.  It is currently marked experimental pending test
results from others that have reported problems on text mounts:
https://cygwin.com/ml/cygwin/2015-03/msg00496.html
https://cygwin.com/ml/cygwin/2015-06/msg00087.html

But assuming it passes those tests, it will be promoted to current,
leaving 4.3.42-3 as the previous version.

NEWS:
=
This is a minor build that fixes an upstream typo that broke bash
behavior when reading scripts from a text mount, regardless of whether
you used the igncr option.  Thanks to Jeff Downs for helping isolate the
problem.

This build of bash is immune to the ShellShock vulnerabilities (although
unpatched bash 4.3 is vulnerable, the official upstream patches solve
the issue).  By now, you should no longer be running a vulnerable bash,
but to double check you can run the following test to make sure you are
not subject to arbitrary remote code execution due to ShellShock:
$ env 'bad=() { echo vulnerable; }' bash -c bad

If it prints "bash: bad: command not found", your version of bash is
safe and not subject to remote exploits.  If it prints "vulnerable", you
need to upgrade now.

There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by
default.
2. d2u is your friend.  You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file.  If you
absolutely must use files with \r\n line endings, consider mounting the
directory where those files live as a text mount.  However, text mounts
are not as well tested or supported on the cygwin mailing list, so you
may encounter other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific set option, named "igncr",
to force bash to ignore \r, independently of cygwin's mount style.  As
of bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files.  I hope to convince the upstream bash maintainer to
accept this patch into a future bash release even on Linux, rather than
keeping it a cygwin-specific patch, but only time will tell.  There are
several ways to activate this option:
4a. For a single affected script, add this line just after the she-bang:
 (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the option, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired.  Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it.  It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks
the current state of 'set -o igncr'.  If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make
sense to support the option through both set and shopt, and SHELLOPTS
proved to be more powerful.
5. You can also experiment with the IFS variable for controlling how
bash will treat \r during variable expansion.
6. There are varying levels of speed at which bash operates.  The
fastest is on a binary mount with igncr disabled (the default behavior).
 Next would be text mounts with igncr disabled and no \r in the
underlying file. Next would be binary mounts with igncr enabled.  And
the slowest that bash will operate is on text mounts with igncr enabled.
7. As additional cygwin extensions, this version of bash includes:
7a. EXECIGNORE - a colon-separated list of glob patterns to ignore
when completing on executables.  EXECIGNORE=*.dll is common.
7b. completion_strip_exe - using 'shopt -s completion_strip_exe'
makes completion strip .exe suffixes
8. This version of bash is immune to ShellShock (CVE-2014-6271 and
friends) because it exports functions via 'BASH_FUNC_foo%%=' rather than
'foo=' environment variables.  However, doing this has exposed
weaknesses in some other utilities like 'ksh' or 'at' that fail to scrub
their environment to exclude what is not a valid name for them.
9. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas.  This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
Thanks to Dan Colascione for providing the EXECIGNORE 

Re: cygwin potentially corrupting permissions?

[Greg Freemyer]

On Thu, Sep 24, 2015 at 3:27 PM, Linda Walsh  wrote:
> Greg Freemyer wrote:
>>
>>
>> Totally logical, but not accurate. )
>
> ---
> What does it say if you do an 'lsacl' on "." (the parent directory).

$ ./lsacl.sh .
[u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] .

But maybe this is interesting.  I just created 2 folders in C:\   .  I
did it at the C:\ level because I can't imagine I ever modified the
ACLs on C:\.

Anyway, one directory was created via "mkdir" in cygwin.  The other
via the file explorer.  Look at how different the ACLs are:

$ mkdir /cygdrive/c/Test-dir-created-in-cygwin

$ ./lsacl.sh /cygdrive/c/Test-dir-created-in-cygwin/
[u::rwx,g::r-x,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x/u::rwx,g::r-x,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x]
/cygdrive/c/Test-dir-created-in-cygwin/

$ ./lsacl.sh /cygdrive/c/Test-dir-created-in-file-explorer/
[u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated
Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---]
/cygdrive/c/Test-dir-created-in-file-explorer/

What's that about?  Again I'm not expert at ACLs, but the ACLs on the
directory created via File Explorer look really strange to me.

> This is a local file system?  NTFS?

Yes, C: drive. It's my local system drive on both computers and NTFS
on both machines.

> Do you have process hacker?  Maybe the writing process has a different
> integrity label or such.

No, but let me know if you still want me to pursue that.  For now I'm
thinking the ACLs on folders created via File Explorer are somehow
getting screwed up.

Thanks
Greg

> Process hacker lets you see what the integrity labels are on files,
> but to see what they are on files you'd have to d/l another util.
> (chml/regil
>
>>
>> - cygwin is not properly maintaining the permissions when it manipulates a
>> file
>
> 
> May not be able to ... Windows trumps cygwin.
> MS-regularly screws w/windows, .. it's like switching to a new
> init system every month... ok.. maybe not quite that bad...
>
>>
>> Either way, I would really like a solution that doesn't involve a
>> manual chmod for every file I create via the normal Windows interface
>> and which I want to work with it in cygwin.
>
> ===
> I can understand that -- that's sorta why I haven't upgraded
> my cygwin lately -- She spent alot of time solving a problem that didn't
> really appear on my system, so changing the whole security system -- well
> I already know that cygwin doesn't respect existing standards or sources.
> (overwrite windows mount points created -- and is shipping a login that
> zeros your environment -- even when passed switch to not do so --
> effectively
> wipes your windows session -- forcing users to copy sessions from static
> files to get around the problem.
>

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