Re: Renaming (with 'mv') very large files is SLOW

[Andrey Repin]

Greetings, cyg...@kosowsky.org!

> I literally am typing something like:
>   mv foo bar

> In Linux, that just edits the file system table & inode...

> UPDATE...
> I just tried a second 'mv' and it was near instantaneous.
> (and similarly with subsequent renaming of the same file)
> So perhaps not a 'Cygwin' thing but something going on within Windows.

> Could it be that the first 'mv' triggered an anti-virus read of the file since
> perhaps it detects it as a new/changed file?

> But if so, would 'mv' (under Task Manager) be showing the 100+ MB/s disk 
> activity?

Install processmanager and check what actual activity is happening on that
file. Is it reading or writing? Who is doing that?


-- 
With best regards,
Andrey Repin
Tuesday, February 1, 2022 11:47:15

Sorry for my terrible english...


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

Cygwin 3.3.4 - cmd to symlinked path doesn't work

[BRISLANE Mark]

Hi,

We had this issue in 3.3.3 and is down as being fixed in 3.3.4-2 but perhaps 
our scenario is slightly different because it's still happening. SERVER1 has a 
folder on D: called folder 1, which is a symlink to "\\server2\share\folder1" - 
created with mklink /D folder1 \\server2\share\folder1

DOMAIN+Administrator@SERVER1 /cygdrive/d
$ ls -l
total 3
drwxr-x---+ 1 Administrators SERVER1+None 0 Jan 28 11:03 '$RECYCLE.BIN'
d---rwx---+ 1 Administrators SYSTEM0 Jan 25 23:07 'System 
Volume Information'
lrwxrwxrwx  1 Administrators DOMAIN+Domain Users   32 Nov  9 10:52  folder1 -> 
//server2/share/folder1

DOMAIN+Administrator@SERVER1 /cygdrive/d
$ cd folder1

DOMAIN+Administrator@SERVER1 /cygdrive/d/folder1
$ cmd
'\\server2\share\folder1'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows>

This used to work in older versions of Cygwin.

Regards,
Mark



Internal

This email is from AXA Partners. It is strictly confidential and may contain 
legally privileged information. If you are not the intended recipient you must 
not copy, disclose or otherwise use such information. If you have received this 
email in error please immediately delete it from your system and email us to 
inform the sender.
 
AXA France IARD S.A. (Branch No: 624115. French Company No: 722 057 460. ACPR 
No: 4022109.) and AXA France Vie S.A (Branch No: 62116. French Company No: 310 
499 959. ACPR No: 5020051.) have a registered office at Building 7000, Atlantic 
Avenue, Westpark Business Campus, Shannon, County Clare. Each company is a 
Société Anonyme registered in France with its registered address at 313, 
Terrasses de l'Arche, 92000 Nanterre, France. The following are directors of 
both AXA France IARD S.A. and AXA France Vie S.A.: Jacques de Peretti (French), 
Alexis Babeau (French), Alain Dubois (French), Renée Habozit (French), Sandra 
le Grand (French), Cécile Moulard (French), Alban de Mailly Nesle (French). 
Martine Bievre (French) is a director AXA France IARD S.A. Christine Sinibardy 
(French) is a director of AXA France Vie S.A.

AXA France IARD S.A. and AXA France Vie S.A. both trade under the name of 'AXA 
Partners – Credit & Lifestyle Protection', are authorised by Autorité de 
Contrôle Prudential et de Résolution (ACPR) in France and are regulated by the 
Central Bank of Ireland for conduct of business rules. 

AXA Partners S.A.S. (Branch No: 908621. French Company No: 813 778 412 RCS 
Nanterre. Orias No: 15006083) has its registered office at Building 7000, 
Atlantic Avenue, Westpark Business Campus, Shannon, County Clare. Sophie Latil 
(French) is the President and CEO of the company.  The company is a private 
limited company registered in France with its registered address at 313 
Terrasses de L’Arche, 92727 Nanterre Cedex, France.

AXA Partners S.A.S. trades under the name of  'AXA Partners – Credit & 
Lifestyle Protection',  is authorised by ORIAS in France and is regulated by 
the Central Bank of Ireland for conduct of business rules.

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

Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work

[Andrey Repin]

Greetings, BRISLANE Mark!

> We had this issue in 3.3.3 and is down as being fixed in 3.3.4-2 but
> perhaps our scenario is slightly different because it's still happening.
> SERVER1 has a folder on D: called folder 1, which is a symlink to
> "\\server2\share\folder1" - created with mklink /D folder1 
> \\server2\share\folder1

> DOMAIN+Administrator@SERVER1 /cygdrive/d
> $ ls -l
> total 3
> drwxr-x---+ 1 Administrators SERVER1+None 0 Jan 28 11:03 '$RECYCLE.BIN'
> d---rwx---+ 1 Administrators SYSTEM0 Jan 25 23:07 'System 
> Volume Information'
> lrwxrwxrwx  1 Administrators DOMAIN+Domain Users   32 Nov  9 10:52  folder1 
> -> //server2/share/folder1

> DOMAIN+Administrator@SERVER1 /cygdrive/d
> $ cd folder1

> DOMAIN+Administrator@SERVER1 /cygdrive/d/folder1
> $ cmd
> '\\server2\share\folder1'
> CMD.EXE was started with the above path as the current directory.
> UNC paths are not supported.  Defaulting to Windows directory.
> Microsoft Windows [Version 10.0.14393]
> (c) 2016 Microsoft Corporation. All rights reserved.

> C:\Windows>

> This used to work in older versions of Cygwin.

The interesting part is that the behavior is dependent on sequence of events.

`mintty bash -i` in a directory:

> $ pwd
> /cygdrive/d/cygwin
> $ cmd
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> D:\cygwin> exit
>
> $ cd $( pwd )
> $ pwd
> /cygdrive/d/cygwin
> $ cmd
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> \\DAEMON1.DARKDRAGON.LAN\arc\cygwin>


-- 
With best regards,
Andrey Repin
Tuesday, February 1, 2022 15:28:28

Sorry for my terrible english...


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

RE: [EXTERNAL] Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work

[BRISLANE Mark]

Hi there,

I wonder if this is OS dependent? I note you're on Windows 7 / Server 2008 R2 
(both EOL by the way!) where as I'm on Windows Server 2016.

The server where this works on an older version of Cygwin is Server 2012 R2, 
and I've copied the cygwin1.dll from that server to my Server 2016 server but 
the issue still happens.

Regards,
Mark


Internal

-Original Message-
From: Andrey Repin  
Sent: Tuesday 1 February 2022 12:47
To: BRISLANE Mark ; cygwin@cygwin.com
Subject: [EXTERNAL] Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work

Greetings, BRISLANE Mark!

> We had this issue in 3.3.3 and is down as being fixed in 3.3.4-2 but 
> perhaps our scenario is slightly different because it's still happening.
> SERVER1 has a folder on D: called folder 1, which is a symlink to 
> "\\server2\share\folder1" - created with mklink /D folder1 
> \\server2\share\folder1

> DOMAIN+Administrator@SERVER1 /cygdrive/d
> $ ls -l
> total 3
> drwxr-x---+ 1 Administrators SERVER1+None 0 Jan 28 11:03 '$RECYCLE.BIN'
> d---rwx---+ 1 Administrators SYSTEM0 Jan 25 23:07 'System 
> Volume Information'
> lrwxrwxrwx  1 Administrators DOMAIN+Domain Users   32 Nov  9 10:52  folder1 
> -> //server2/share/folder1

> DOMAIN+Administrator@SERVER1 /cygdrive/d
> $ cd folder1

> DOMAIN+Administrator@SERVER1 /cygdrive/d/folder1
> $ cmd
> '\\server2\share\folder1'
> CMD.EXE was started with the above path as the current directory.
> UNC paths are not supported.  Defaulting to Windows directory.
> Microsoft Windows [Version 10.0.14393]
> (c) 2016 Microsoft Corporation. All rights reserved.

> C:\Windows>

> This used to work in older versions of Cygwin.

The interesting part is that the behavior is dependent on sequence of events.

`mintty bash -i` in a directory:

> $ pwd
> /cygdrive/d/cygwin
> $ cmd
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> D:\cygwin> exit
>
> $ cd $( pwd )
> $ pwd
> /cygdrive/d/cygwin
> $ cmd
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> \\DAEMON1.DARKDRAGON.LAN\arc\cygwin>


--
With best regards,
Andrey Repin
Tuesday, February 1, 2022 15:28:28

Sorry for my terrible english...

This email is from AXA Partners. It is strictly confidential and may contain 
legally privileged information. If you are not the intended recipient you must 
not copy, disclose or otherwise use such information. If you have received this 
email in error please immediately delete it from your system and email us to 
inform the sender.
 
AXA France IARD S.A. (Branch No: 624115. French Company No: 722 057 460. ACPR 
No: 4022109.) and AXA France Vie S.A (Branch No: 62116. French Company No: 310 
499 959. ACPR No: 5020051.) have a registered office at Building 7000, Atlantic 
Avenue, Westpark Business Campus, Shannon, County Clare. Each company is a 
Société Anonyme registered in France with its registered address at 313, 
Terrasses de l'Arche, 92000 Nanterre, France. The following are directors of 
both AXA France IARD S.A. and AXA France Vie S.A.: Jacques de Peretti (French), 
Alexis Babeau (French), Alain Dubois (French), Renée Habozit (French), Sandra 
le Grand (French), Cécile Moulard (French), Alban de Mailly Nesle (French). 
Martine Bievre (French) is a director AXA France IARD S.A. Christine Sinibardy 
(French) is a director of AXA France Vie S.A.

AXA France IARD S.A. and AXA France Vie S.A. both trade under the name of 'AXA 
Partners – Credit & Lifestyle Protection', are authorised by Autorité de 
Contrôle Prudential et de Résolution (ACPR) in France and are regulated by the 
Central Bank of Ireland for conduct of business rules. 

AXA Partners S.A.S. (Branch No: 908621. French Company No: 813 778 412 RCS 
Nanterre. Orias No: 15006083) has its registered office at Building 7000, 
Atlantic Avenue, Westpark Business Campus, Shannon, County Clare. Sophie Latil 
(French) is the President and CEO of the company.  The company is a private 
limited company registered in France with its registered address at 313 
Terrasses de L’Arche, 92727 Nanterre Cedex, France.

AXA Partners S.A.S. trades under the name of  'AXA Partners – Credit & 
Lifestyle Protection',  is authorised by ORIAS in France and is regulated by 
the Central Bank of Ireland for conduct of business rules.

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

Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work

[Corinna Vinschen]

On Feb  1 15:47, Andrey Repin wrote:
> Greetings, BRISLANE Mark!
> 
> > We had this issue in 3.3.3 and is down as being fixed in 3.3.4-2 but
> > perhaps our scenario is slightly different because it's still happening.
> > SERVER1 has a folder on D: called folder 1, which is a symlink to
> > "\\server2\share\folder1" - created with mklink /D folder1 
> > \\server2\share\folder1
> 
> > DOMAIN+Administrator@SERVER1 /cygdrive/d
> > $ ls -l
> > total 3
> > drwxr-x---+ 1 Administrators SERVER1+None 0 Jan 28 11:03 '$RECYCLE.BIN'
> > d---rwx---+ 1 Administrators SYSTEM0 Jan 25 23:07 'System 
> > Volume Information'
> > lrwxrwxrwx  1 Administrators DOMAIN+Domain Users   32 Nov  9 10:52  folder1 
> > -> //server2/share/folder1
> 
> > DOMAIN+Administrator@SERVER1 /cygdrive/d
> > $ cd folder1
> 
> > DOMAIN+Administrator@SERVER1 /cygdrive/d/folder1
> > $ cmd
> > '\\server2\share\folder1'
> > CMD.EXE was started with the above path as the current directory.
> > UNC paths are not supported.  Defaulting to Windows directory.
> > Microsoft Windows [Version 10.0.14393]
> > (c) 2016 Microsoft Corporation. All rights reserved.
> 
> > C:\Windows>
> 
> > This used to work in older versions of Cygwin.
> 
> The interesting part is that the behavior is dependent on sequence of events.
> 
> `mintty bash -i` in a directory:
> 
> > $ pwd
> > /cygdrive/d/cygwin
> > $ cmd
> > Microsoft Windows [Version 6.1.7601]
> > Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
> >
> > D:\cygwin> exit

Not sure how you did that, but I can't reproduce this, and I'm pretty
certain the CMD failure is how Cygwin works for a long time.  I get this
same behaviour back to Cygwin 3.1.7, which is where I stopped testing.

The reason is this:

Reparse points created with mklink /d are evaluated as symlinks. This
reparse point contains an absolute UNC path.  If you cd to this dir in
Cygwin, Cygwin evaluates the path and reads the symlink content.  Given
the content is an absolute path, the symlink content replaces the
entire path.  Internally the CWD is stored twice, once in POSIX, once
in Windows syntax.  In short, what happens is this:

  pwd   ->  POSIX(/cygdrive/d), WIN(D:)
  cd cygwin ->  
open reparse point "cygwin"
read content == "\\server2\share\folder1"
convert to POSIX == "//server2/share/folder1"
restart path evaluation and check for further symlinks
-> no further symlinks
convert path to Windows == "\\server2\share\folder1"
store both paths as new CWD
  pwd   ->  POSIX(//server2/share/folder1),
WIN(\\server2\share\folder1)

So what happens in bash?

  $ pwd
  /cygdrive/d
  $ cd cygwin
  $ pwd
  /cygdrive/d/cygwin
  $ /bin/pwd
  //server2/share/folder1

pwd is a builtin command.  It works differently from /bin/pwd in that
bash pwd does not cd to a dir and then reads the dir stored in the OS
again.  Rather it just appends the new dir as has been given on the CLI.
There's a setting somewhere to make bash reevaluate the CWD all the time
but I don't know it off the top of my head.

Bottom line is, that *in fact* the CWD in the underlying Cygwin layer is
the share, not the drive letter path.  And that's what any subsequently
started process gets as CWD, CMD just as well as any Cygwin process.

If you want CMD to succeed in this scenario all the time, you have to
start CMD in /cygdrive/d and then pushd or cd to the cygwin dir.  CMD
will not evaluate the reparse point as symlink and just go ahead.

Alternatively, just use powershell if you need a native shell.  Powershell
has no problem with UNC paths as CWD.

I hope that explains it sufficiently.


Corinna

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

Re: setup-*.exe --help default explanation re -D/-L options [Was: [ANNOUNCEMENT] Updated: setup (2.917)]

[Jon Turney]

On 31/01/2022 22:11, Adam Dinwoodie wrote:

On  Mon, 31 Jan 2022 12:56:13 -0700, Brian Inglis wrote:

On 2022-01-31 08:46, Andrey Repin wrote:

Greetings, Jon Turney!


Probably what's wanted is to remember the state of those checkboxes, if
this isn't the first time setup has been run?


That's a feature silently longed for for a loong time. :) But this is such a
low priority, very few people actually mentioned it in the past years.


It could usefully be added similarly to last-action:

$ fgrep -A1 action /etc/setup/setup.rc
last-action
Download,Install

last-shortcut:
Desktop|StartMenu|none,...


This reminded me of a bug report I've been meaning to properly
characterise and report for a while, and also pointed me at a
workaround...

Currently, running `setup-*.exe --help` produces output that includes
the following:

 -D --download   Download packages from internet only
 -L --local-install  Install packages from local directory only

 The default is to both download and install packages, unless either
 --download or --local-install is specified.

I think the descriptions for the `-D` and `-L` options are misleading,
at least in combination with that final line, which is definitely wrong.
As I understand it, the actual behaviour would be better described by
something like the below:

 -D --download   Download packages from internet only, unless -L
 is also specified
 -L --local-install  Install packages from local directory only,
 unless -D is also specified


One could just remove the word 'only'?



 If neither --download nor --local-install is specified, the default
 is to repeat the same action as from the previous run.  If no
 previous run can be found, the default is to perform both actions,
 and both actions can be explicitly requested by specifying both
 --download and --local-install.


Note that I tweaked the behaviour of this a bit in [1]

[1] 
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=commit;h=147fc15d0222e050779b18a209991c258d85944f


I think that makes the current help text accurately describe 
non-interactive mode.


There are some cases in interactive mode which are obscure (e.g. '-M' 
without '-D' or '-L' gets you whatever mode you used last time without 
showing you what it was, but I'm not sure if that needs to be here.



In particular, the fact that the two options currently say they will
"only" do their action, and that the default is to perform both, lead me
to believe (a) the options were mutually exclusive and one would
presumably override the other, (b) this was probably a legacy from
before setup.rc stored the previous action, and therefore (c) if I was
running setup with `-q` or `-M`, there was no way to get the supposedly
default "do both" behaviour; I'd instead need to go through the full
GUI.

Having now seen how this setting is stored, I've realised I can just
call setup with `-DL` and it'll perform both actions again.  But I think
my assumption that "default" was supposed to mean "default always" not
"default only on first run" wasn't *entirely* PEBCAK (even if it mostly
was), so that help text would definitely benefit from being made a bit
more explicit.

(I'm aware my suggestion above is decidedly wordy; it's not intended to
be exactly what I think is required, only a first pass at clarifying the
key details I think are missing.)


Perhaps the best thing would be to have something like 
'--mode={download, install, somebetterwordforboth}' and document '-D' 
and '-L' as short aliases for forms of that (which makes the modality 
clear).



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

Re: [ANNOUNCEMENT] cygwin 3.3.4-1

[Jim Reisert AD1C]

> > The following packages have been uploaded to the Cygwin distribution:
> >
> > * cygwin-3.3.4-1
> > * cygwin-devel-3.3.4-1
> > * cygwin-doc-3.3.4-1
>
> I've tried two mirrors, both with the same result:
>
> dash.exe - Bad Image
>
> C:\Cygwin64\bin\cygwin1.dll is either not designed to run on
> Windows or it contains an errorError status 0xc07b.


Seems to be resolved with 3.3.4-2.

Thanks!

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

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

Re: [PATCH cygport 1/2] postinst: Never remove an existing .gnu_debuglink

[Jon Turney]

On 01/02/2022 19:22, Corinna Vinschen wrote:

Hi Jon,

On Feb  1 17:25, Jon Turney wrote:

Be more careful not to remove an existing .gnu_debuglink, even if we
think this package has no useful debug symbols.

(Some versions of 'llvm-objdump -l' fail to find line number info even
though it's there.  Don't break a package which manages it's own debug
symbols (e.g. cygwin) when that happens.)
---
  lib/src_postinst.cygpart | 28 ++--
  1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
index d8bb226..e29b2cb 100644
--- a/lib/src_postinst.cygpart
+++ b/lib/src_postinst.cygpart
@@ -1051,23 +1051,31 @@ __prepstrip() {
  
  			lines=$(${objdump} -d -l "${exe}" 2>/dev/null | sed -ne "s|.*\(/usr/src/debug/${PF}/.*\):[0-9]*$|\1|gp" | sort -u | tee -a ${T}/.dbgsrc.out | wc -l);


Shouldn't lines be computed *after* the new check for .gnu_deb?  After
all, it's still pretty time-consuming and if the .gnu_deb check kicks in
it's never tested...


The objdump invocation has the side effect of creating ${T}/.dbgsrc.out, 
which is later used to determine what source files to put into the 
debuginfo package.




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

Re: setup-*.exe --help default explanation re -D/-L options [Was: [ANNOUNCEMENT] Updated: setup (2.917)]

[Adam Dinwoodie]

On Tue, Feb 01, 2022 at 04:53:47PM +, Jon Turney wrote:
> On 31/01/2022 22:11, Adam Dinwoodie wrote:
> > On  Mon, 31 Jan 2022 12:56:13 -0700, Brian Inglis wrote:
> > > On 2022-01-31 08:46, Andrey Repin wrote:
> > > > Greetings, Jon Turney!
> > > > 
> > > > > Probably what's wanted is to remember the state of those checkboxes, 
> > > > > if
> > > > > this isn't the first time setup has been run?
> > > > 
> > > > That's a feature silently longed for for a loong time. :) But this is 
> > > > such a
> > > > low priority, very few people actually mentioned it in the past years.
> > > 
> > > It could usefully be added similarly to last-action:
> > > 
> > >   $ fgrep -A1 action /etc/setup/setup.rc
> > >   last-action
> > >   Download,Install
> > > 
> > > last-shortcut:
> > >   Desktop|StartMenu|none,...
> > 
> > This reminded me of a bug report I've been meaning to properly
> > characterise and report for a while, and also pointed me at a
> > workaround...
> > 
> > Currently, running `setup-*.exe --help` produces output that includes
> > the following:
> > 
> >  -D --download   Download packages from internet only
> >  -L --local-install  Install packages from local directory only
> > 
> >  The default is to both download and install packages, unless either
> >  --download or --local-install is specified.
> > 
> > I think the descriptions for the `-D` and `-L` options are misleading,
> > at least in combination with that final line, which is definitely wrong.
> > As I understand it, the actual behaviour would be better described by
> > something like the below:
> > 
> >  -D --download   Download packages from internet only, unless -L
> >  is also specified
> >  -L --local-install  Install packages from local directory only,
> >  unless -D is also specified
> 
> One could just remove the word 'only'?

...yes, that would in fact work, and is clear.

> >  If neither --download nor --local-install is specified, the default
> >  is to repeat the same action as from the previous run.  If no
> >  previous run can be found, the default is to perform both actions,
> >  and both actions can be explicitly requested by specifying both
> >  --download and --local-install.
> 
> Note that I tweaked the behaviour of this a bit in [1]
> 
> [1] 
> https://cygwin.com/git/?p=cygwin-apps/setup.git;a=commit;h=147fc15d0222e050779b18a209991c258d85944f
> 
> I think that makes the current help text accurately describe non-interactive
> mode.
> 
> There are some cases in interactive mode which are obscure (e.g. '-M'
> without '-D' or '-L' gets you whatever mode you used last time without
> showing you what it was, but I'm not sure if that needs to be here.

Ah, okay.  I think I hit this with `-M` and assumed -- evidently
incorrectly -- that the same behaviour would exist for `-q`.  I agree
the current text is entirely accurate for the fully non-interactive
mode.

I think this caught me out because I frequently run with `-M` -- I don't
care about most of the options, but I do want to see what packages are
about to be updated -- and I almost never want to use the download-only
or install-only modes.  But I used `-L` as a one-off when I was
uninstalling and reinstalling a bunch of packages and didn't want to hit
the network every time, then forgot about it.  And it wasn't until I was
musing about the fact that I hadn't seen any package updates for a few
weeks when trying to do my regular updates with `-M` that I realised
what had happened...

Given all that, I think everything seems sensible except for the fact
that `-M` doesn't follow the same behaviour as `-q`.

> > In particular, the fact that the two options currently say they will
> > "only" do their action, and that the default is to perform both, lead me
> > to believe (a) the options were mutually exclusive and one would
> > presumably override the other, (b) this was probably a legacy from
> > before setup.rc stored the previous action, and therefore (c) if I was
> > running setup with `-q` or `-M`, there was no way to get the supposedly
> > default "do both" behaviour; I'd instead need to go through the full
> > GUI.
> > 
> > Having now seen how this setting is stored, I've realised I can just
> > call setup with `-DL` and it'll perform both actions again.  But I think
> > my assumption that "default" was supposed to mean "default always" not
> > "default only on first run" wasn't *entirely* PEBCAK (even if it mostly
> > was), so that help text would definitely benefit from being made a bit
> > more explicit.
> > 
> > (I'm aware my suggestion above is decidedly wordy; it's not intended to
> > be exactly what I think is required, only a first pass at clarifying the
> > key details I think are missing.)
> 
> Perhaps the best thing would be to have something like '--mode={download,
> install, somebetterwordforboth}' and document '-D' and '-L' as short aliases
> for forms of t

cygwin 3.3.4-2: "GetConsoleMode()" may be missing "Quick Edit Mode", "Insert Mode" state

[Mitchell Hentges]

This issue only manifests when using Windows Command Prompt as the terminal
instead of MinTTY.

When querying Windows for "GetConsoleMode()" of the input handle, a result
of 0x0007 is returned.
When calling "GetConsoleMode()" from a Command Prompt (outside of Cygwin),
0x00F7 is returned.

In both these cases (on my machine), if I right-click the title bar, and
click on Properties, I can see that "Quick Edit Mode" and "Insert Mode" are
both checked. So, in both of them, I'd expect that at least the bits at 0x0040
and 0x0020 
respectively will be enabled.

To reproduce this:
1. Compile the following program ("cl ") to print the console mode:
#include 

int main(void)
{
HANDLE pdc_con_in = GetStdHandle(STD_INPUT_HANDLE);
DWORD mode;
GetConsoleMode(pdc_con_in, &mode);
printf("Console mode: %04X", mode);
}
2. Run cygwin using "Cygwin.bat"
3. Run the program that prints the console mode
4. Verify the console modes in your Command Prompt properties dialog.

This is causing issues such as fzf not being able to reset the console mode
properly .



-- 
Mitchell Hentges
Engineering Workflow
Mozilla


cygcheck.out
Description: Binary data

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

[ANNOUNCEMENT] Updated: libwebp{, -devel, 7, decoder3, demux2, mux3} 1.2.2

[Cygwin libwebp Maintainer]

The following packages have been upgraded in the Cygwin distribution:

* libwebp   1.2.2
* libwebp-devel 1.2.2
* libwebp7  1.2.2
* libwebpdecoder3   1.2.2
* libwebpdemux2 1.2.2
* libwebpmux3   1.2.2

WebP is a modern web image format with superior compression.
WebP lossless images are 26% smaller in size compared to PNGs.
Lossless WebP supports (alpha channel) transparency at a cost of 22% overhead.
WebP lossy images are 25-34% smaller than JPEG images at equivalent quality.
Lossy WebP supports transparency with 3× smaller file sizes than PNG.
A WebP file consists of VP8 or VP8L image data in a RIFF container.

For more information see the project home page:

https://developers.google.com/speed/webp/

As there are multiple components and changes each release please
see below or read /usr/share/doc/libwebp/NEWS after installation;
for complete details of changes see:

/usr/share/doc/libwebp/ChangeLog
or

https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v1.2.2/ChangeLog


version 1.2.2   1/11/2022
This is a binary compatible release.
* webpmux: add "-set bgcolor A,R,G,B"
* add ARM64 NEON support for MSVC builds
* fix duplicate include error in Xcode when using multiple XCFrameworks
  in a project
* doc updates and bug fixes

version 1.2.1   7/20/2021
This is a binary compatible release.
* minor lossless encoder improvements and x86 color conversion speed up
* add ARM64 simulator support to xcframeworkbuild.sh
* further security related hardening in libwebp & examples
* toolchain updates and bug fixes
* use more inclusive language within the source

version 1.2.0   12/23/2020
* API changes: - libwebp: encode.h: add a qmin/qmax range for quality
  factor (cwebp adds -qrange)
* lossless encoder improvements
* SIMD support for Wasm builds
* add xcframeworkbuild.sh, supports Mac Catalyst builds
* import fuzzers from oss-fuzz & chromium
* webpmux: add an '-set loop ' option
* toolchain updates and bug fixes

version 1.1.0   12/18/2019
* API changes: - libwebp: WebPMalloc - extras: WebPUnmultiplyARGB
* alpha decode fix
* toolchain updates and bug fixes

version 1.0.3   7/4/2019
This is a binary compatible release.
* resize fixes for Nx1 sizes and the addition of non-opaque alpha values
  for odd sizes
* lossless encode/decode performance improvements
* lossy compression performance improvement at low quality levels with
  flat content
* python swig files updated to support python 3
Tool updates: vwebp will now preserve the aspect ratio of images that
exceed monitor resolution by scaling the image to fit

version 1.0.2   1/14/2019
This is a binary compatible release.
* (Windows) unicode file support in the tools
* lossless encoder speedups
* lossy encoder speedup on ARM
* lossless multi-threaded security fix

version 1.0.1   11/2/2018
This is a binary compatible release.
* lossless encoder speedups
* big-endian fix for alpha decoding
* gif2webp fix for loop count=65535 transcode
* further security related hardening in libwebp & libwebpmux
* miscellaneous bug & build fixes

version 1.0.0   4/2/2018
This is a binary compatible release.
* lossy encoder improvements to avoid chroma shifts in various
  circumstances
* big-endian fixes for decode, RGBA import and WebPPictureDistortion
Tool updates:
gifwebp, anim_diff - default duration behavior (<= 10ms) changed to
match web browsers, transcoding tools
img2webp, webpmux - allow options to be passed in via a file


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