setup-x86_64.exe can not create download folder

[David Balažic via Cygwin]

Hi!

 I just downloaded https://www.cygwin.com/setup-x86_64.exe   version 2.925

After starting, I:
 - selected "Install from Internet" (actually it was already selected)
 - left defaults: root dir=C:\cygwin64 , Install For: all users
 - the Local Package Directory was: C:\Users\AdminGuy\Downloads\
   I added cygwin_download_temp to it to get:
C:\Users\AdminGuy\Downloads\cygwin_download_temp

After clicking I got an error dialog:

---
Cygwin Setup
---
Directory C:\Users\AdminGuy\Downloads\cygwin_download_temp does not
exist, would you like me to create it?
---
Yes   No
---

I clicked Yes and got an error that it could not create the directory.
So I created the folder in Explorer and then continued.

Notes: I tried to reproduce it in a second instance of
setup-x86_64.exe but could not, it created the folder without a
problem.

So I closed (clicked the Cancel button) both instances and run it
again, and I could reproduce the problem. After changing the local
path, I pressed the enter key instead of clicking next. The in the
error dialog asking to create the folder, I pressed space. Then I got
the dialog:

---
Cygwin Setup
---
Couldn't create directory , sorry.  (Is drive full or read-only?)
---
OK
---


Very strange, sometimes clicking Yes in the "would you like me to
create it" dialog just brings up the same dialog again and again,
until a few iterations is shows the "Couldn't create directory ,
sorry." dialog.

Can be workarounded, but a bit annoying.

OS: Windows Server 2019 version 1809

When I start setup-x86_64.exe the UAC dialog pops up where I click Yes.

Regards,
David

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

Duplicates in /proc/partitions

[David Balažic via Cygwin]

Before, during and after plugging in a n USB stick:

$ cat /proc/partitions
major minor  #blocks  name   win-mounts

8 0 1000204632 sda
8 1102400 sda1
8 2 16384 sda2
8 3 999571820 sda3   C:\
8 4510976 sda4

$ cat /proc/partitions
major minor  #blocks  name   win-mounts

8 0 1000204632 sda
8 1102400 sda1
8 2 16384 sda2
8 3 999571820 sda3   C:\
8 4510976 sda4
816  62522712 sdb
817   4096000 sdb1   D:\
818  58424664 sdb2
816  62522712 sdb
817   4096000 sdb1   D:\
818  58424664 sdb2   E:\

$ cat /proc/partitions
major minor  #blocks  name   win-mounts

8 0 1000204632 sda
8 1102400 sda1
8 2 16384 sda2
8 3 999571820 sda3   C:\
8 4510976 sda4
816  62522712 sdb
817   4096000 sdb1   D:\
818  58424664 sdb2   E:\


So the second listing shows sdb twice. Also E: does not seem to exist
(see below).

After that I run:

$ cygcheck -s -v -r > cygcheck.out
cygcheck: dump_sysinfo: GetVolumeInformation() for drive E: failed: 1005

In attached cygcheck.out i swapped out company name and abbreviation with .

Windows sees no E: drive:

DISKPART> list volume

  Volume ###  Ltr  LabelFs TypeSize Status Info
  --  ---  ---  -  --  ---  -  
  Volume 0 CNTFS   Partition953 GB  HealthyBoot
  Volume 1  FAT32  Partition100 MB  HealthySystem
  Volume 2  NTFS   Partition499 MB  HealthyHidden
  Volume 3 D   FFT2 FATRemovable   4000 MB  Healthy

(there is no mention of E: in Disk Management GUI either)


Regards,
David

-- 
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: Conflict if same username local and in domain

[David Balažic via Cygwin]

I don't have any of  /user /users /User /Users folders on my setup.
Do you mean C:\Users ?

Even if I symlink it, won't that just change the location, but not the
used usernames?

As for /etc/passwd , I don't have that file.
/etc/nsswitch.conf  is empty (only comments).

It is basically a fresh cygwin (64) installation with default settings.

Regards,
David

On Thu, 29 Oct 2020 at 21:42, L A Walsh  wrote:
>
> On 2020/10/29 05:39, David Balažic via Cygwin wrote:
> > Hi!
> >
> > I started Cygwin Terminal to find out, I landed in the other users
> > home folder and have no write access.
> >
> 
> I have the same username, but not the same "home" directory.
> The user that signs in 1st gets the short name, the 2nd login gets
> the domain or system name appended like
> /users/linda/local-account
> /users/linda.domain/domain account.
>
> Both of the user names have uniq windows UUID's and I have both in my
> /etc/passwd.
>
> The two directories SHARE many of the same files -- so both my logins
> are in a common 'local' group (like 'lindaGroup'), and since the machine
> is in the domain, I can create a 'domain\lindagroup' and on my local
> machine, both logins are in that group -- for that matter, the domain group
> is also in the local group -- so theoretically I could just put both logins
> in the domain group.
>
> Anwyay, it DOES work -- it just has to be configured right.
>
> So you say you got /home/joe for both -- but don't they have a /user
> directory
> that is different for each?
>
> just point your /home/=>/User, or if you really want them separate, then
> have /home/joe point to /Users/joe/home, and the domain should get
> joe.dom so /home/joe.dom => /Users/joe.dom/home.
>
> I started with my /home dir pointed at my the same dir as my /users dir, so
> by default, windows separated them.
>
> Both my userid and username are different -- have 2 entries in /etc/passwd:
>
> Bliss\linda:*:5013:201:L A
> Walsh,U-Bliss\linda,S-1-5-21-3-7-3-5013:/Users/linda.Bliss:/bin/bash
> linda:*:1000:1015:U-Athenae\linda,S-1-5-21-188-75-11-1000:/Users/linda:/bin/bash
>
>
>
--
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

Conflict if same username local and in domain

[David Balažic via Cygwin]

Hi!

I started Cygwin Terminal to find out, I landed in the other users
home folder and have no write access.

What happened was:
 - log into Windows as domain user DOM\JOE
 - start cygwin shell, land in /home/joe
 - log into Windows as local user JOE
 - start cygwin shell, land in /home/joe , but with no write access,
as it belongs to other user according to Windows


Is this a known issue? Should cygwin use a different username?
Help.

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

latest openssh can not connect to older server

[David Balažic via Cygwin]

Hi!

I tried to backup some files from my server with scp and failed:

$ scp  -v  root@the.server:/root/a.file  .
Executing: program /usr/bin/ssh host the.server, user root, command
scp -v -f /root/a.file
OpenSSH_8.2p1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Connecting to the.server [192.168.1.11] port 22.
debug1: Connection established.
debug1: identity file /home/stein/.ssh/id_rsa type -1
debug1: identity file /home/stein/.ssh/id_rsa-cert type -1
debug1: identity file /home/stein/.ssh/id_dsa type -1
debug1: identity file /home/stein/.ssh/id_dsa-cert type -1
debug1: identity file /home/stein/.ssh/id_ecdsa type -1
debug1: identity file /home/stein/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/stein/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/stein/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/stein/.ssh/id_ed25519 type -1
debug1: identity file /home/stein/.ssh/id_ed25519-cert type -1
debug1: identity file /home/stein/.ssh/id_ed25519_sk type -1
debug1: identity file /home/stein/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/stein/.ssh/id_xmss type -1
debug1: identity file /home/stein/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version dropbear_2011.54
debug1: no match: dropbear_2011.54
debug1: Authenticating to the.server:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: (no match)
Unable to negotiate with 192.168.1.11 port 22: no matching key
exchange method found. Their offer:
diffie-hellman-group1-sha1,diffie-hellman-group14-sha1


I tried OpenSSH_8.0p1-2 which is still available in the cygwin
setup-x86_64.exe wizard and that version works fine.
(the version above is 8.2.p1-1 in the setup wizard)

Regards,
David
--
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

pread() from /dev/sda fails with: Illegal seek

[David Balažic]

Hi!

I'm porting an app from Linux to Cygwin and stumbled on this problem:

pread on /dev/sda fails with Illegal seek.

The simplified code is:

#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
  unsigned int sector_size = 512;
  void *buf = calloc(sector_size,1);
  int fd = open("/dev/sda", O_DIRECT | O_RDONLY);
  if (-1 == pread(fd, buf, sector_size, 0)) {
perror("pread failed");
  }
}

# g++ test.cc
# ./a  # run as adnministrator
pread failed: Illegal seek

Why is that?

cygcheck -s output attached.

Summary: cygwin 3.1.2-1  , Windows 8.1 , all 64 bit

Regards,
David


cygcheck-s
Description: Binary data

--
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: lrzip-0.631-1: pthread_createResource temporarily unavailable

[David Balažic]

I tried the same, but on a local (NTFS) volume and there it completed
with no error.
Will do some more tests and report...

On Sun, 16 Jun 2019 at 22:05, David Balažic  wrote:
>
> Hi!
>
> Using cygwin64 with latest updates, I got this error after running
> lrzip (for hours):
>
>
> $ lrzip -v sda.2019-apr-01.local
> The following options are in effect for this COMPRESSION.
> Threading is ENABLED. Number of CPUs detected: 4
> Detected 17168990208 bytes ram
> Compression level 7
> Nice Value: 19
> Show Progress
> Verbose
> Temporary Directory set as: /tmp/
> Compression mode is: LZMA. LZO Compressibility testing enabled
> Heuristically Computed Compression Window: 109 = 10900MB
> Output filename is: sda.2019-apr-01.local.lrz
> Warning, unable to set permissions on sda.2019-apr-01.local.lrz
> File size: 128035676160
> Will take 12 passes
> Beginning rzip pre-processing phase
> Beginning rzip pre-processing phase
> Beginning rzip pre-processing phase
> Beginning rzip pre-processing phase
> Beginning rzip pre-processing phase
> Beginning rzip pre-processing phase
> Beginning rzip pre-processing phase
> Beginning rzip pre-processing phase
> Beginning rzip pre-processing phase
> pthread_createResource temporarily unavailable
> Fatal error - exiting
>
> There is a created file with size 2640192 and name
> sda.2019-apr-01.local.lrz in the same folder, after the crash.
>
> Googling that error line find only one case:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623745
> It is from year 2011 and is supposedly patched.
>
> The $PWD is /cygdrive/z/tmp  which is a CIFS/SMB mount from a my NAS.
>
> Regards,
> David

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

lrzip-0.631-1: pthread_createResource temporarily unavailable

[David Balažic]

Hi!

Using cygwin64 with latest updates, I got this error after running
lrzip (for hours):


$ lrzip -v sda.2019-apr-01.local
The following options are in effect for this COMPRESSION.
Threading is ENABLED. Number of CPUs detected: 4
Detected 17168990208 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Temporary Directory set as: /tmp/
Compression mode is: LZMA. LZO Compressibility testing enabled
Heuristically Computed Compression Window: 109 = 10900MB
Output filename is: sda.2019-apr-01.local.lrz
Warning, unable to set permissions on sda.2019-apr-01.local.lrz
File size: 128035676160
Will take 12 passes
Beginning rzip pre-processing phase
Beginning rzip pre-processing phase
Beginning rzip pre-processing phase
Beginning rzip pre-processing phase
Beginning rzip pre-processing phase
Beginning rzip pre-processing phase
Beginning rzip pre-processing phase
Beginning rzip pre-processing phase
Beginning rzip pre-processing phase
pthread_createResource temporarily unavailable
Fatal error - exiting

There is a created file with size 2640192 and name
sda.2019-apr-01.local.lrz in the same folder, after the crash.

Googling that error line find only one case:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623745
It is from year 2011 and is supposedly patched.

The $PWD is /cygdrive/z/tmp  which is a CIFS/SMB mount from a my NAS.

Regards,
David


cygcheck.out
Description: Binary data

--
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: File not visible in cygwin

[David Balažic]

Thanks, the file had the temporary attribute.
Regards,
David


On Sun, 9 Dec 2018 at 19:32, Marco Atzeri  wrote:

> Am 09.12.2018 um 18:57 schrieb David Balažic:
> > Hi!
> >
> > NOTE: This seems to be fixed in latest version.
> >
> > Yesterday i was doing a 'find . -type f -print0' on my PC and noticed,
> that
> > one file was missing in the output.
> > Then I CD-ed into that folder and issued a ls -l, it printed:
> > total 0
> >
> > In Windows Explorer I could see that there is one file in that folder.
> >
> > As I was rushing to do the job, I just run the setup and updated to the
> > latest version, without any special investigation.
> >
> > With the updated cygwin, the file became visible.
> >
> > I checked today the release notes for the last few Cygwin versions and
> did
> > not see anything that fits the description.
> > Is this some known issue?
> >
>
> https://cygwin.com/ml/cygwin/2018-03/msg00140.html
>
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
>
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>
>

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

File not visible in cygwin

[David Balažic]

Hi!

NOTE: This seems to be fixed in latest version.

Yesterday i was doing a 'find . -type f -print0' on my PC and noticed, that
one file was missing in the output.
Then I CD-ed into that folder and issued a ls -l, it printed:
total 0

In Windows Explorer I could see that there is one file in that folder.

As I was rushing to do the job, I just run the setup and updated to the
latest version, without any special investigation.

With the updated cygwin, the file became visible.

I checked today the release notes for the last few Cygwin versions and did
not see anything that fits the description.
Is this some known issue?

Anyone interested in more details?

One interesting point: after the update, there were two "Cygin64 Terminal"
entries in the start menu/screen (displayed when I typed "cyg" into the
search box).
Today, after a reboot, there is again only a single entry.

Current cygcheck  -s  output (trimmed):

Cygwin Configuration Diagnostics
Current System Time: Sun Dec 09 17:54:01 2018

Windows 2012 R2 Server Standard Ver 6.3 Build 9600

Running in Terminal Service session

Path:   C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0

   Cygwin DLL version info:
DLL version: 2.11.2
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 329
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5

Question: is there a simple way to find out what the version of cygwin was
before the last update?


Regards,
David

--
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: setup 2.887 release candidate - please test

[David Balažic]

On 7 February 2018 at 01:49, Steven Penny  wrote:

> On Tue, 6 Feb 2018 15:04:49, Jon Turney wrote:
>
>> - Query the user for action to take if a corrupt local file is found
>>
>
> works great - thanks
>
> - 'Current' is replaced by 'Best' (which is slightly different in ways
>> it's difficult to summarize briefly) and 'Sync' (which exposes the
>> --force-current (distupgrade) option through the UI).
>>
>
> i get the desire for one word labels - but im not sure how good "sync" is.
> its
> not clear in the GUI what it does, and frankly, even reading your
> description
> doesnt clear up for me what it does. i guess i would need to run "--help"
> and
> see what "--force-current" does to figure it out. that just seems like
> more work
> than it should be.
>
>  This could be improved by having a tooltip on the GUI item, explaining in
a sentence or two, what it does.

Regards,
David

--
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 in lrzip 0.631-1 (32 bit version) with -d -o - options

[David Balažic]

This still doesn't work.
All current versions, including cygwin 2.8.0-1.

Result same as in above testcase.
64 bit version works fine.

PS: Compressing the test.iso (or its already compressed version) in 32
bit environment with:
lrzip  -o doppel.lrz  test.iso(.lrz)
Gives:
Unable to malloc buffer of size 309956175 in flush_buffer
Fatal error - exiting

So in 32 bit, lrzip is seriously borken and should maybe be removed.


Regards,
David

On 5 February 2017 at 15:19, David Balažic <xerc...@gmail.com> wrote:
> On 5 February 2017 at 07:37, Marco Atzeri <marco.atz...@gmail.com> wrote:
>> can you check if latest cygwin test solves the issue ?
>
> I did, it doesn't, see my previous message in thread.
>
> David

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

Setup v2.879 - can not scroll package list

[David Balažic]

In the "Select Packages" part of the installer dialog, I selected in
the "View" dropdown menu "Not Installed" and then tried to scroll thru
the list using the mouse wheel.

But it does not scroll the package list, instead it changes the
selection in the mentioned drop down menu. Even after clicking inside
the list control.

Apparently clicking in the package list does not move the focus to it.

It is the same in 32 bit and 64 bit version.

Regards,
David

--
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: problem with nc 1.107-4

[David Balažic]

On 30 March 2017 at 04:24, 高锋  wrote:
> I just installed the latest nc 1.107-4 on windows 7 platform.When lauched
> the command like:
> nc -vuz 10.31.28.188 6110
> ,each time it reported connecting successed,even if the target ip
> 10.31.28.188 does not really exists.

What exactly does it say?
Because with UDP there are no connections, so there can not be any
successful connection.

Regards,
David

--
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: Cygwin 2.7.0-1

[David Balažic]

The problem described in the thread "Bug in lrzip 0.631-1 (32 bit
version) with -d -o - options"
persists with this update. (guessing it might be related to the pipi changes)

Regards,
David

On 12 February 2017 at 13:53, Corinna Vinschen
 wrote:
> Hi folks,
>
>
> I uploaded a new Cygwin release 2.7.0-1
>
> ===
>
> What's new:
> ---
>
> - Support for /proc//environ.
>
> - New API: getentropy, getrandom, NL_LOCALE_NAME.
>
>
> What changed:
> -
>
>
> Bug Fixes
> -
>
> - Fix rename(2) fail with EACCES if newfile is in use.
>   Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00108.html
>
> - Always try to write all incoming bytes to blocking pipes, as required
>   by POSIX.
>   Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00087.html
>
> - Fix handling of Alt-Numpad sequences in console handler.
>   Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00135.html
>
> - Fix erasing UTF-8 multibyte characters in cooked mode.
>   Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00299.html
>
> - Fix handling of a literal '+' by cygcheck -p
>   Addresses:  https://cygwin.com/ml/cygwin/2014-01/msg00287.html
>
> - Fix limited Internet speeds caused by inappropriate socket buffering.
>   Addresses: https://cygwin.com/ml/cygwin-patches/2017-q1/msg00010.html
>
> ===
>
>
> Have fun,
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>

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

Re: Console buffer width always 1 column less than setting

[David Balažic]

On 6 February 2017 at 18:54, Marco Atzeri wrote:
>
> the problem is that  email address in clear will be reported on the
> web archive and  will be easy accessible to spam bot looking
> for email address.
>
> It is specifically mentioned on:
> https://cygwin.com/lists.html

That would be even better if it listed ways to to that (configuring MUAs).
For example I use gmail and googled for "configure gmail to not quote
email address (in replies)" but got nothing useful.

Regards,
David

--
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 in lrzip 0.631-1 (32 bit version) with -d -o - options

[David Balažic]

On 5 February 2017 at 07:37, Marco Atzeri  wrote:
> can you check if latest cygwin test solves the issue ?

I did, it doesn't, see my previous message in thread.

David

--
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 in lrzip 0.631-1 (32 bit version) with -d -o - options

[David Balažic]

Here is a smaller reproducible test case (I did the preparation part
in 64 bit cygwin):

 - download http://releases.ubuntu.com/16.10/ubuntu-16.10-desktop-i386.iso
 - download http://releases.ubuntu.com/16.10/ubuntu-16.10-desktop-amd64.iso

$ md5sum ubuntu-16.10-desktop-i386.iso ubuntu-16.10-desktop-amd64.iso
e9e9a6c6b3c8c265788f4e726af25994 *ubuntu-16.10-desktop-i386.iso
3f50877c05121f7fd8544bef2d722824 *ubuntu-16.10-desktop-amd64.iso

$ cat ubuntu-16.10-desktop-i386.iso ubuntu-16.10-desktop-amd64.iso > test.iso

$ md5sum test.iso
d6e8cb13ce36e2c04961004782eec139 *test.iso

$ lrzip -v test.iso
The following options are in effect for this COMPRESSION.
Threading is ENABLED. Number of CPUs detected: 4
Detected 17160601600 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Temporary Directory set as: /tmp/
Compression mode is: LZMA. LZO Compressibility testing enabled
Heuristically Computed Compression Window: 109 = 10900MB
Output filename is: test.iso.lrz
File size: 3204448256
Will take 1 pass
Beginning rzip pre-processing phase
test.iso - Compression Ratio: 1.352. Average Compression Speed: 15.357MB/s.
Total time: 00:03:18.85

$ lrzip -i test.iso.lrz
test.iso.lrz:
lrzip version: 0.6 file
Compression: rzip + lzma
Decompressed file size: 3204448256
Compressed file size: 2370391407
Compression ratio: 1.352
MD5 used for integrity testing
MD5: d6e8cb13ce36e2c04961004782eec139

in 32 bit cygwin:

$ TMP=/cygdrive/d/tmp/  lrzip -v  -d  -o -
/cygdrive/c/cygwin64/home/stein/test.iso.lrz  | tee >(md5sum --tag)
>(sha1sum --tag) > /dev/null
The following options are in effect for this DECOMPRESSION.
Threading is ENABLED. Number of CPUs detected: 4
Detected 17160601600 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Output Filename Specified: -
Temporary Directory set as: /cygdrive/d/tmp/
Outputting to stdout.
Detected lrzip version 0.6 file.
MD5 being used for integrity testing.
Decompressing...
Unable to decompress entirely in ram, will use physical files
Dumping temporary file to control->outFILE.

Average DeCompression Speed: 29.105MB/s
Dumping temporary file to control->outFILE.
[OK] - 3204448256 bytes
Total time: 00:01:45.07
SHA1 (-) = da39a3ee5e6b4b0d3255bfef95601890afd80709
MD5 (-) = d41d8cd98f00b204e9800998ecf8427e

The MD5 sum is wrong. (both md5 and sha1 values are the hashes of an
empty file, so the data is lost somewhere)

I attach the cygcheck -s -v -r output again (with cygwin 2.7.0-0.1 , I
later checked with 2.7.0-0.2 too, got the same results)

Regards,
David


On 1 February 2017 at 22:25, David Balažic <xerc...@gmail.com> wrote:
> I tried the  2.7.0-0.1  test release and now the behavior changed.
>
> Before I got consistently a wrong MD5 sum of 8bd6ad48f2cea6a710af70b434d57673
> With this release I get c43a02c309fa5e0abe778201e9ceec46.
>
> So something changed.
>
> Either the problem is in cygwin or lrzip, I guess.
>
> Regards,
> David
>
>
> On 30 January 2017 at 16:23, David Balažic <xerc...@gmail.com> wrote:
>> I tried in Ubuntu 32 bit (both the packaged lrzip  and a self compiled
>> one) and there the problem does not happen, so it looks like either:
>>  - bad lrzip in cygwin
>>  - cygwin pipe issues?
>>
>> Regards,
>> David
>>
>>
>> On 25 January 2017 at 23:15, David Balažic <xerc...@gmail.com> wrote:
>>> Hi!
>>>
>>> The 32 bit version of lrzip 0.631-1 contains a bug that corrupts the
>>> decompressed dat in some circumstances.
>>>
>>> I reproduced the problem on 2 PCs (the md5sum of the broken output was
>>> the same on both systems).
>>>
>>> I seems to happen when the (de)compressed file size is bigger than the
>>> available RAM (note that the 32 bit version uses max 4GB in any case)
>>> and lrzip resorts to using a temporary file.
>>>
>>> See below for reproducing:
>>>
>>> $ lrzip -i sda.img.lrz2
>>> sda.img.lrz2:
>>> lrzip version: 0.6 file
>>> Compression: rzip + lzma
>>> Decompressed file size: 64017212928
>>> Compressed file size: 7210541304
>>> Compression ratio: 8.878
>>> MD5 used for integrity testing
>>> MD5: 6594f5b0d22efd345003260054165842
>>>
>>> $ date; df -h ; TMP=/cygdrive/i/t/tmp/  lrzip -v  -d  -o -
>>> sda.img.lrz2  | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null   ;
>>> date
>>> Tue Jan 24 21:29:01 CET 2017
>>> Filesystem  Size  Used Avail Use% Mounted on
>>> C:/cygwin   114G   94G   21G  83% /
>>> D:  541G  534G  7.1G  99% /cygdrive/d
>>> I:  391G  279G  113G  72% /cygdrive/i
>>> Q:   60G   57G  2.8G  96% /cygdrive/q
>>> The following options are in

Re: Bug in lrzip 0.631-1 (32 bit version) with -d -o - options

[David Balažic]

I tried the  2.7.0-0.1  test release and now the behavior changed.

Before I got consistently a wrong MD5 sum of 8bd6ad48f2cea6a710af70b434d57673
With this release I get c43a02c309fa5e0abe778201e9ceec46.

So something changed.

Either the problem is in cygwin or lrzip, I guess.

Regards,
David


On 30 January 2017 at 16:23, David Balažic <xerc...@gmail.com> wrote:
> I tried in Ubuntu 32 bit (both the packaged lrzip  and a self compiled
> one) and there the problem does not happen, so it looks like either:
>  - bad lrzip in cygwin
>  - cygwin pipe issues?
>
> Regards,
> David
>
>
> On 25 January 2017 at 23:15, David Balažic <xerc...@gmail.com> wrote:
>> Hi!
>>
>> The 32 bit version of lrzip 0.631-1 contains a bug that corrupts the
>> decompressed dat in some circumstances.
>>
>> I reproduced the problem on 2 PCs (the md5sum of the broken output was
>> the same on both systems).
>>
>> I seems to happen when the (de)compressed file size is bigger than the
>> available RAM (note that the 32 bit version uses max 4GB in any case)
>> and lrzip resorts to using a temporary file.
>>
>> See below for reproducing:
>>
>> $ lrzip -i sda.img.lrz2
>> sda.img.lrz2:
>> lrzip version: 0.6 file
>> Compression: rzip + lzma
>> Decompressed file size: 64017212928
>> Compressed file size: 7210541304
>> Compression ratio: 8.878
>> MD5 used for integrity testing
>> MD5: 6594f5b0d22efd345003260054165842
>>
>> $ date; df -h ; TMP=/cygdrive/i/t/tmp/  lrzip -v  -d  -o -
>> sda.img.lrz2  | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null   ;
>> date
>> Tue Jan 24 21:29:01 CET 2017
>> Filesystem  Size  Used Avail Use% Mounted on
>> C:/cygwin   114G   94G   21G  83% /
>> D:  541G  534G  7.1G  99% /cygdrive/d
>> I:  391G  279G  113G  72% /cygdrive/i
>> Q:   60G   57G  2.8G  96% /cygdrive/q
>> The following options are in effect for this DECOMPRESSION.
>> Threading is ENABLED. Number of CPUs detected: 4
>> Detected 17160601600 bytes ram
>> Compression level 7
>> Nice Value: 19
>> Show Progress
>> Verbose
>> Output Filename Specified: -
>> Temporary Directory set as: /cygdrive/i/t/tmp/
>> Outputting to stdout.
>> Detected lrzip version 0.6 file.
>> MD5 being used for integrity testing.
>> Decompressing...
>> Unable to decompress entirely in ram, will use physical files
>> Dumping temporary file to control->outFILE.
>>
>> [1]+  Stopped TMP=/cygdrive/i/t/tmp/ lrzip -v -d -o -
>> sda.img.lrz2 | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null
>> Tue Jan 24 21:31:39 CET 2017
>>
>> stein@hofer8 /cygdrive/i/Zotac_bak
>> $ fg
>> TMP=/cygdrive/i/t/tmp/ lrzip -v -d -o - sda.img.lrz2 | tee >(md5sum
>> --tag) >(sha1sum --tag) > /dev/null
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>> Dumping temporary file to control->outFILE.
>>
>> Average DeCompression Speed:  0.668MB/s
>> Dumping temporary file to control->outFILE.
>> [OK] - 64017212928 bytes
>> Total time: 25:22:26.25
>> SHA1 (-) = 6c519210541eb128c03b7c0f803adb2b46ee2a72
>> MD5 (-) = 8bd6ad48f2cea6a710af70b434d57673
>>
>>
>> The correct md5sum is 6594f5b0d22efd345003260054165842.
>>
>>
>> Simply decompressing the file (lrzip -d -o sda.img sda.img.lrz2) to
>> filesystem works fine, only when piped to stdout the problem happens.
>>
>> The 64 bit version does not have this problem.
>>
>>
>> I will check if the same problem happens with the native linux build
>> of lrzip (it takes a day...).
>>
>>
>> I tried to reproduce the problem with a smaller file, but there it did
>> not happen. Maybe my first test file has some corruption that causes
>> this (unlikely).
>>
>> Some version information (complete cygcheck -s -v -r output attached):
>>
>> base-cygwin   3.8-1
>> cygwin2.6.1-1
>> lrzip 0.631-1
>>
>> Regards,
>> David

--
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 in lrzip 0.631-1 (32 bit version) with -d -o - options

[David Balažic]

I tried in Ubuntu 32 bit (both the packaged lrzip  and a self compiled
one) and there the problem does not happen, so it looks like either:
 - bad lrzip in cygwin
 - cygwin pipe issues?

Regards,
David


On 25 January 2017 at 23:15, David Balažic <xerc...@gmail.com> wrote:
> Hi!
>
> The 32 bit version of lrzip 0.631-1 contains a bug that corrupts the
> decompressed dat in some circumstances.
>
> I reproduced the problem on 2 PCs (the md5sum of the broken output was
> the same on both systems).
>
> I seems to happen when the (de)compressed file size is bigger than the
> available RAM (note that the 32 bit version uses max 4GB in any case)
> and lrzip resorts to using a temporary file.
>
> See below for reproducing:
>
> $ lrzip -i sda.img.lrz2
> sda.img.lrz2:
> lrzip version: 0.6 file
> Compression: rzip + lzma
> Decompressed file size: 64017212928
> Compressed file size: 7210541304
> Compression ratio: 8.878
> MD5 used for integrity testing
> MD5: 6594f5b0d22efd345003260054165842
>
> $ date; df -h ; TMP=/cygdrive/i/t/tmp/  lrzip -v  -d  -o -
> sda.img.lrz2  | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null   ;
> date
> Tue Jan 24 21:29:01 CET 2017
> Filesystem  Size  Used Avail Use% Mounted on
> C:/cygwin   114G   94G   21G  83% /
> D:  541G  534G  7.1G  99% /cygdrive/d
> I:  391G  279G  113G  72% /cygdrive/i
> Q:   60G   57G  2.8G  96% /cygdrive/q
> The following options are in effect for this DECOMPRESSION.
> Threading is ENABLED. Number of CPUs detected: 4
> Detected 17160601600 bytes ram
> Compression level 7
> Nice Value: 19
> Show Progress
> Verbose
> Output Filename Specified: -
> Temporary Directory set as: /cygdrive/i/t/tmp/
> Outputting to stdout.
> Detected lrzip version 0.6 file.
> MD5 being used for integrity testing.
> Decompressing...
> Unable to decompress entirely in ram, will use physical files
> Dumping temporary file to control->outFILE.
>
> [1]+  Stopped TMP=/cygdrive/i/t/tmp/ lrzip -v -d -o -
> sda.img.lrz2 | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null
> Tue Jan 24 21:31:39 CET 2017
>
> stein@hofer8 /cygdrive/i/Zotac_bak
> $ fg
> TMP=/cygdrive/i/t/tmp/ lrzip -v -d -o - sda.img.lrz2 | tee >(md5sum
> --tag) >(sha1sum --tag) > /dev/null
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
> Dumping temporary file to control->outFILE.
>
> Average DeCompression Speed:  0.668MB/s
> Dumping temporary file to control->outFILE.
> [OK] - 64017212928 bytes
> Total time: 25:22:26.25
> SHA1 (-) = 6c519210541eb128c03b7c0f803adb2b46ee2a72
> MD5 (-) = 8bd6ad48f2cea6a710af70b434d57673
>
>
> The correct md5sum is 6594f5b0d22efd345003260054165842.
>
>
> Simply decompressing the file (lrzip -d -o sda.img sda.img.lrz2) to
> filesystem works fine, only when piped to stdout the problem happens.
>
> The 64 bit version does not have this problem.
>
>
> I will check if the same problem happens with the native linux build
> of lrzip (it takes a day...).
>
>
> I tried to reproduce the problem with a smaller file, but there it did
> not happen. Maybe my first test file has some corruption that causes
> this (unlikely).
>
> Some version information (complete cygcheck -s -v -r output attached):
>
> base-cygwin   3.8-1
> cygwin2.6.1-1
> lrzip 0.631-1
>
> Regards,
> David

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

Bug in lrzip 0.631-1 (32 bit version) with -d -o - options

[David Balažic]

Hi!

The 32 bit version of lrzip 0.631-1 contains a bug that corrupts the
decompressed dat in some circumstances.

I reproduced the problem on 2 PCs (the md5sum of the broken output was
the same on both systems).

I seems to happen when the (de)compressed file size is bigger than the
available RAM (note that the 32 bit version uses max 4GB in any case)
and lrzip resorts to using a temporary file.

See below for reproducing:

$ lrzip -i sda.img.lrz2
sda.img.lrz2:
lrzip version: 0.6 file
Compression: rzip + lzma
Decompressed file size: 64017212928
Compressed file size: 7210541304
Compression ratio: 8.878
MD5 used for integrity testing
MD5: 6594f5b0d22efd345003260054165842

$ date; df -h ; TMP=/cygdrive/i/t/tmp/  lrzip -v  -d  -o -
sda.img.lrz2  | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null   ;
date
Tue Jan 24 21:29:01 CET 2017
Filesystem  Size  Used Avail Use% Mounted on
C:/cygwin   114G   94G   21G  83% /
D:  541G  534G  7.1G  99% /cygdrive/d
I:  391G  279G  113G  72% /cygdrive/i
Q:   60G   57G  2.8G  96% /cygdrive/q
The following options are in effect for this DECOMPRESSION.
Threading is ENABLED. Number of CPUs detected: 4
Detected 17160601600 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Output Filename Specified: -
Temporary Directory set as: /cygdrive/i/t/tmp/
Outputting to stdout.
Detected lrzip version 0.6 file.
MD5 being used for integrity testing.
Decompressing...
Unable to decompress entirely in ram, will use physical files
Dumping temporary file to control->outFILE.

[1]+  Stopped TMP=/cygdrive/i/t/tmp/ lrzip -v -d -o -
sda.img.lrz2 | tee >(md5sum --tag) >(sha1sum --tag) > /dev/null
Tue Jan 24 21:31:39 CET 2017

stein@hofer8 /cygdrive/i/Zotac_bak
$ fg
TMP=/cygdrive/i/t/tmp/ lrzip -v -d -o - sda.img.lrz2 | tee >(md5sum
--tag) >(sha1sum --tag) > /dev/null
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.
Dumping temporary file to control->outFILE.

Average DeCompression Speed:  0.668MB/s
Dumping temporary file to control->outFILE.
[OK] - 64017212928 bytes
Total time: 25:22:26.25
SHA1 (-) = 6c519210541eb128c03b7c0f803adb2b46ee2a72
MD5 (-) = 8bd6ad48f2cea6a710af70b434d57673


The correct md5sum is 6594f5b0d22efd345003260054165842.


Simply decompressing the file (lrzip -d -o sda.img sda.img.lrz2) to
filesystem works fine, only when piped to stdout the problem happens.

The 64 bit version does not have this problem.


I will check if the same problem happens with the native linux build
of lrzip (it takes a day...).


I tried to reproduce the problem with a smaller file, but there it did
not happen. Maybe my first test file has some corruption that causes
this (unlikely).

Some version information (complete cygcheck -s -v -r output attached):

base-cygwin   3.8-1
cygwin2.6.1-1
lrzip 0.631-1

Regards,
David


cygcheck.out
Description: Binary data

--
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: Pipe behavior clarification?

[David Balažic]

On 23 January 2017 at 15:32, Eric Blake <ebl...@redhat.com> wrote:
> On 01/22/2017 04:23 PM, Eliot Moss wrote:
>> On 1/22/2017 3:19 PM, David Balažic wrote:
>>> Hi!
>>>
>>> Is this a correct pipe behavior?
>>>
>>> $ echo booo | tee >(md5sum --tag) >/dev/null
>>> MD5 (-) = 9c8b79bdf79ef0ee73a77b8d36d27a2d
>>>
>>> $ echo booo | tee >(md5sum --tag) | cat >/dev/null
>>
>> Here's what I think happens, even if it is a bit counter-intuitive:
>>
>>>(...) creates a subprocess, whose input comes from some kind
>> of pipe or socket, and tee is presented with a filename it can
>> use to write to that socket.
>>
>> The *output* of the >(...) subprocess is hooked up to what is
>> known to be the output of tee *at the time the subprocess is
>> created*.  This happens *before* any > redirections are done.
>
> Rather, all >() and > redirections are performed in left-to-right order.
>  But you are correct that the second >/dev/null is overwriting the
> stdout that was originally given by >(md5sum), and therefore tee is NOT
> writing to the md5sum process.

The last part is incorrect. tee is always writing to the md5sum process.
It can be verified by redirecting the md5sum output to a file, like
>(md5sum > file1),
or redirecting the final output to a file instead of /dev/null. In
both cases the (correct)
md5 hash will be there.

Regards,
David

PS: I verified on SLES 11 that the behavior is the same as in cygwin,
so the thread is "technically closed".

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

Pipe behavior clarification?

[David Balažic]

Hi!

Is this a correct pipe behavior?

$ echo booo | tee >(md5sum --tag) >/dev/null
MD5 (-) = 9c8b79bdf79ef0ee73a77b8d36d27a2d

$ echo booo | tee >(md5sum --tag) | cat >/dev/null

It surprised me, that the output of md5sum is dealed the same way as
the std output of tee in the second case, but separately in the first
case.

Using cygwin 64 bit (up to date), with bash.

Regards,
David

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

Huge cache usage while making hdd image with dd

[David Balažic]

Hi!

On Windows 8.1 Update 1 Professional with cygwin 2.4.1 (not the
latest, I know, I'll recheck under 2.5.1 later),
I am running this command:

dd if=/dev/sdb bs=1M | tee sdb.1TB.test | sha256sum > sdb.1TB.test.sha256

the destination folder in on an external drive (NTFS, more detail below).

The CPU usage is about 40% (4 core Intel i5-2320) and the current
copying speed is 60 MB/s (measured by signaling USR1 to dd and
doubleckecking in the task manager).

The weird thing is OS disk cache usage.
Task manager show this for RAM usage (16GB physical RAM in system, 16
GB fixed size pagefile - on sdb):
In use: 1.7 GB
Available: 13.7 GB
Cached: 14,3 GB (!)
Committed: 2,8/32 GB
Paged pool: 277 MB
Non-paged pool: 126 MB

$ cat /proc/meminfo
MemTotal:   16758408 kB
MemFree:14409844 kB
HighTotal: 0 kB
HighFree:  0 kB
LowTotal:   16758408 kB
LowFree:14409844 kB
SwapTotal:  16777216 kB
SwapFree:   16233228 kB

perfmon.exe shows about 4% pagefile usage.

The symptoms are:
 - starting programs is slow. Starting explorer.exe takes 2-3 seconds
versus instant as normal (C: is a SSD)
 - after a while if left alone programs get stuck (swapped). For
example Firefox. If left alone (unused) for a minute and the I try to
click a link or scroll the page, it takes about 10 seconds during
which the window title shows "Not responding"


A simple copy operation should not occupy so much cache IMO.
I post here, as cygwin is involved.


Any idea what is going on?
Where to look?

Some system info:

Intel i5-2320
16 GB RAM
Intel H61 chipset

C: Samsung SSD 830  128GB

source drive (sdb) is an internal Hitachi HDS721010CLA332 (1 TB)

 * Seagate Desktop Expansion 5TB external drive, connected over USB3.0

Regards,
David Balažic

--
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: cmp (or echo) bug?

[David Balažic]

cat and diff work as expected:

$ cat  <(echo echo1)  <(echo echo2)
echo1
echo2


$ diff  <(echo echo1)  <(echo echo2)
1c1
< echo1
---
> echo2


So maybe the bug is really in cmp.

Regards,
David


On 29 December 2015 at 17:43, Houder <hou...@xs4all.nl> wrote:
> On 2015-12-25 22:32, David Balažic wrote:
>>
>> Hi!
>>
>> In Cygwin terminal (bash) I typed:
>>
>> cmp  <(echo echo1)  <(echo echo2)
>>
>> This does not print anything.
>> Not even with -b.
>>
>> On Linux (Ubuntu 12.04 in VMWare) it reports that the inputs are
>> different.
>>
>> Bug?
>> Or am I missing something?
>
>
> @@ uname -a
> CYGWIN_NT-6.1-WOW Seven 2.3.1(0.291/5/3) 2015-11-14 12:42 i686 Cygwin
> @@ ./cmp <(echo echo1) <(echo echo2)
> /dev/fd/63 /dev/fd/62 differ: byte 5, line 1
> @@ ./cmp <(echo echo1) <(echo echo2)
> /dev/fd/63 /dev/fd/62 differ: byte 5, line 1
> @@ ./cmp <(echo echo1) <(echo echo2)
> /dev/fd/63 /dev/fd/62 differ: byte 5, line 1
> @@ ./cmp <(echo echo1) <(echo echo2)
> /dev/fd/63 /dev/fd/62 differ: byte 5, line 1
> @@ ./cmp <(echo echo1) <(echo echo2)
> /dev/fd/63 /dev/fd/62 differ: byte 5, line 1
> @@ ./cmp <(echo echo1) <(echo echo2)
> /dev/fd/63 /dev/fd/62 differ: byte 5, line 1
>
> etc.
>
> But only after I had modified cmp.c (diffutils) as follows:
>
> int
> main (int argc, char **argv)
> {
> ...
>
> #if 0
>   if (file_desc[f1] < 0 || fstat (file_desc[f1], stat_buf + f1) != 0)
> #else
>   if (file_desc[f1] < 0 || f1 ? ( stat (file[1], stat_buf + f1) != 0 )
>   : ( stat (file[0], stat_buf + f1) != 0 ) )
> // Henri: suspect fstat
> #endif
> {
>   if (file_desc[f1] < 0 && comparison_type == type_status)
> exit (EXIT_TROUBLE);
>   else
> error (EXIT_TROUBLE, errno, "%s", file[f1]);
> }
> }
>
>   /* If the files are links to the same inode and have the same file
> position,
>  they are identical.  */
>
>   if (0 < same_file (_buf[0], _buf[1])
>   && same_file_attributes (_buf[0], _buf[1])
>   && file_position (0) == file_position (1))
> { // Henri: diagnostics
> #if 0
> printf("same_file = %d\n", same_file (_buf[0], _buf[1]) );
> printf("same_file_attributes = %d\n", same_file_attributes
> (_buf[0], _buf[1]) );
> printf("same file pos = %d\n", file_position (0) == file_position (1) );
> #endif
> printf("file[0] = %s, file[1] = %s\n", file[0], file[1]);
> printf("file_desc[0] = %d, file_desc[1] = %d\n", file_desc[0],
> file_desc[1]);
> printf("bailing out: same file.\n");
> return EXIT_SUCCESS;
> }
>
> Regards,
> Henri
>
>
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>

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

Re: cmp (or echo) bug?

[David Balažic]

It is irrelevant how it is implemented. The command means "compare the
output of those two commands" and the only correct result is "they
differ on byte 5".

It is clearly a bug.

--
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: cmp (or echo) bug?

[David Balažic]

I tried it in zsh (32 bit cygwin) and there it works correctly:

$  cmp  <(echo echo1)  <(echo echo2)
/tmp/zshirbIJ1 /tmp/zshDsdZep differ: byte 5, line 1

So it seems the bug is in bash.

Regards,
David


On 26 December 2015 at 13:49, Ismail Donmez <ism...@i10z.com> wrote:
> Hi,
>
> David Balažic  gmail.com> writes:
>
>> In Cygwin terminal (bash) I typed:
>>
>> cmp  <(echo echo1)  <(echo echo2)
>
> I suspect its a bash bug since it works fine with zsh (tested 64bit only).

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

cmp (or echo) bug?

[David Balažic]

Hi!

In Cygwin terminal (bash) I typed:

cmp  <(echo echo1)  <(echo echo2)

This does not print anything.
Not even with -b.

On Linux (Ubuntu 12.04 in VMWare) it reports that the inputs are different.

Bug?
Or am I missing something?

I just updated to latest version of cygwin, to be sure.
32 bit version.
On Windows 8.1 Pro x64 (all updates)

Regards,
David

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

mbuffer or similar app?

[David Balažic]

Hi!

Is there a port of mbuffer or a similar tool to cygwin?

David

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

Error on update, cygutils.sh exit code 127

[David Balažic]

Hi!

I started the latest setup.exe (version 2.774), clicked Next,Next,Next
(aka update my cygwin installation, a less clicking way would be
welcome) and at the end it printed:

Package: cygutils
cygutils.sh exit code 127

/var/log/setup.log.full has this at the end:

Installing file cygfile:///usr/share/doc/Cygwin/
Installing file cygfile:///usr/share/doc/Cygwin/openssh.README
2013/03/18 14:28:04 Changing gid back to original
Visited: 112 nodes out of 2759 while creating dependency order.
Dependency order of packages: base-cygwin sed gzip libpcre0 gettext
grep gawk tzcode libgmp3 libattr1 libncurses10 texinfo
_update-info-dir libreadline7 terminfo libstdc++6 libncursesw10
libiconv2 libintl8 bash coreutils cygwin libgcc1 dash rebase
_autorebase alternatives zlib0 apngopt findutils base-files binutils
libbz2_1 bzip2 ca-certificates liblzma5 diffutils less xz tar cpio
crypt editrights csih cvs cvsps cygrunsrv libpopt0 dos2unix cygutils
groff man cygwin-doc file w32api-headers w32api-runtime w32api
mingw-w32api mingw-runtime libintl3 gcc-mingw-core gcc-core ipc-utils
libcom_err2 libroken18 libasn1_8 libuuid1 libblkid1 libheimbase1
libopenssl100 libwind0 libhx509_5 libsqlite3_0 libkrb5_26 libheimntlm0
libgssapi3 libidn11 libdb4.5 libsasl2 libopenldap2_4_2 libssh2_1
libcurl4 libedit0 libexpat1 libgpg-error0 libgcrypt11 libgdbm4
liblzo2_2 libp11-kit0 libtasn1_3 libgnutls26 libkafs0 libopenldap2_3_0
libopenssl098 libsigsegv2 libssp0 libwrap0 libxml2 login make mintty
openssh perl_vendor perl perl-Error pv pv-debuginfo run util-linux
wdiff wget which
2013/03/18 14:28:04 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/update-info-dir.sh
2013/03/18 14:28:06 running: cmd.exe /c
C:\cygwin\etc\postinstall\autorebase.bat
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll:
skipped because nonexistent.

The following DLLs couldn't be rebased because they were in use:
  /usr/bin/cygreadline7.dll
  /usr/bin/cygncursesw-10.dll
  /usr/bin/cygintl-8.dll
  /usr/bin/cygiconv-2.dll
  /usr/bin/cyggcc_s-1.dll
2013/03/18 14:28:11 Changing gid to Administrators
2013/03/18 14:28:30 note: Installation Complete
2013/03/18 14:28:30 Ending cygwin install



Hmm, only now I see the date is old. So I'm lost and open for suggestions.

Regards,
David

--
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: Error on update, cygutils.sh exit code 127

[David Balažic]

Oh, only after the install wizard is closed it the log file updated.
Now it says:


2013/05/17 14:49:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/update-info-dir.sh
2013/05/17 14:50:00 running: cmd.exe /c
C:\cygwin\etc\postinstall\autorebase.bat
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll:
skipped because nonexistent.
2013/05/17 14:50:04 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/cygutils.sh
/etc/postinstall/cygutils.sh: line 1:
/usr/bin/update-desktop-database: No such file or directory
/etc/postinstall/cygutils.sh: line 2: /usr/bin/update-mime-database:
No such file or directory
2013/05/17 14:50:04 abnormal exit: exit code=127
2013/05/17 14:50:04 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/man.sh
2013/05/17 14:50:04 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/libxml2.sh
2013/05/17 14:50:05 Changing gid to Administrators
2013/05/17 15:02:27 note: Installation Complete
2013/05/17 15:02:27 Ending cygwin install


The same thing happened on another PC, so I guess this is some bug int
he postinstall scripts.

Regards,
David

On 17 May 2013 15:02, David Balažic xerc...@gmail.com wrote:
 Hi!

 I started the latest setup.exe (version 2.774), clicked Next,Next,Next
 (aka update my cygwin installation, a less clicking way would be
 welcome) and at the end it printed:

 Package: cygutils
 cygutils.sh exit code 127

 /var/log/setup.log.full has this at the end:

 Installing file cygfile:///usr/share/doc/Cygwin/
 Installing file cygfile:///usr/share/doc/Cygwin/openssh.README
 2013/03/18 14:28:04 Changing gid back to original
 Visited: 112 nodes out of 2759 while creating dependency order.
 Dependency order of packages: base-cygwin sed gzip libpcre0 gettext
 grep gawk tzcode libgmp3 libattr1 libncurses10 texinfo
 _update-info-dir libreadline7 terminfo libstdc++6 libncursesw10
 libiconv2 libintl8 bash coreutils cygwin libgcc1 dash rebase
 _autorebase alternatives zlib0 apngopt findutils base-files binutils
 libbz2_1 bzip2 ca-certificates liblzma5 diffutils less xz tar cpio
 crypt editrights csih cvs cvsps cygrunsrv libpopt0 dos2unix cygutils
 groff man cygwin-doc file w32api-headers w32api-runtime w32api
 mingw-w32api mingw-runtime libintl3 gcc-mingw-core gcc-core ipc-utils
 libcom_err2 libroken18 libasn1_8 libuuid1 libblkid1 libheimbase1
 libopenssl100 libwind0 libhx509_5 libsqlite3_0 libkrb5_26 libheimntlm0
 libgssapi3 libidn11 libdb4.5 libsasl2 libopenldap2_4_2 libssh2_1
 libcurl4 libedit0 libexpat1 libgpg-error0 libgcrypt11 libgdbm4
 liblzo2_2 libp11-kit0 libtasn1_3 libgnutls26 libkafs0 libopenldap2_3_0
 libopenssl098 libsigsegv2 libssp0 libwrap0 libxml2 login make mintty
 openssh perl_vendor perl perl-Error pv pv-debuginfo run util-linux
 wdiff wget which
 2013/03/18 14:28:04 running: C:\cygwin\bin\bash.exe --norc --noprofile
 /etc/postinstall/update-info-dir.sh
 2013/03/18 14:28:06 running: cmd.exe /c
 C:\cygwin\etc\postinstall\autorebase.bat
 /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll:
 skipped because nonexistent.

 The following DLLs couldn't be rebased because they were in use:
   /usr/bin/cygreadline7.dll
   /usr/bin/cygncursesw-10.dll
   /usr/bin/cygintl-8.dll
   /usr/bin/cygiconv-2.dll
   /usr/bin/cyggcc_s-1.dll
 2013/03/18 14:28:11 Changing gid to Administrators
 2013/03/18 14:28:30 note: Installation Complete
 2013/03/18 14:28:30 Ending cygwin install



 Hmm, only now I see the date is old. So I'm lost and open for suggestions.

 Regards,
 David

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

Setup.exe - pending view does not show all pending packages

[David Balažic]

Hi!

If I start Setup.exe v2.774 on a PC where cygwin is already installed
and I select to install new package (not yet installed), then the
Pending view only shows this selected package and misses all the other
pending packages (they would be upgraded as a newer version is
available).


Without selecting new packages to install, the Pending vie shows a
list of existing packages that will be updated.

So this is inconsistent and confusing/misleading.

Regards,
David

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

web archive is xenophobic (non ASCII characters problems)

[David Balažic]

http://cygwin.com/ml/cygwin/2013-05/

This page displays non ASCII characters wrongly.
Namely the 'ž' in my last name.

Also when showing the message content:
http://cygwin.com/ml/cygwin/2013-05/msg00239.html


Regards,
David

--
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: date command shows time 20 minutes into future

[David Balažic]

After a reboot, it all works correctly again.

Windows, I guess... :p

Regards,
David

On 27 January 2012 21:17, David Balažic  wrote:
 Hi!

 Just to note, the UTC printout is wrong too, so I assume this has
 nothing to do with timezones.

 European time is UTC+1 currently.

 TZ=CET date
 This prints he same time as with no TZ. (the difference being only the
 CE(S)T string)

 Regards,
 David

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

date command shows time 20 minutes into future

[David Balažic]

Hi!

I'm running an up to date version of cygwin (update a week ago or so)
on Windows XP Pro SP3.

Today I noticed the date command prints the wrong time:
 - actual wall clock time: 10:47
 - date output: Fri Jan 27 11:07:38 CEST 2012
 - date -u: Fri Jan 27 10:08:01 UTC 2012
 - windows system time (as in systray) : 10:48

Any clue?

Regards,
David

PS: I just run Setup to update and the only new packages are openssl,
vim, xterm and xxd

--
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: date command shows time 20 minutes into future

[David Balažic]

Hi!

Just to note, the UTC printout is wrong too, so I assume this has
nothing to do with timezones.

European time is UTC+1 currently.

TZ=CET date
This prints he same time as with no TZ. (the difference being only the
CE(S)T string)

Regards,
David

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

Incomplete installation of subversion

[David Balažic]

Hi!

I have a reasonably up to date cygwin installation (did an update a
week ago or so).
Today I run the latest setup (v2.708). In Pending I saw a few libX
packages and minttty 0.8.1.

Then I selected subversion for install.
On Next I got a dialog saying that subversion depended on additional packages.
I clicked... I don't really remember what, I guess it was OK or Yes.

Then it installed subversion and the updates.

But when I started mintty and entered svn, I got this:

$ svn
/usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory

I started Setup again, and now under Pending I see:
 - wouldn't it be wonderful to be able to copy paste text from dialogs?
 - crypt
 - libgdm4
 - libopenldap2_3_0
 - libopenssl098
 - libpq5
 - libproxy0
 - minires

So what did I do wrong?

I am waiting with the install of the above packages in case you have a
question about the current state of my system.

Regards,
David

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

Setup.exe update confusion

[David Balažic]

Hi!

I just downloaded and started Setup.exe (version 2.708).

I have already Cygwin installed, I wnated just to update to newest state.

So I clicked Next, until I got to the package selection.

Before I used then to click the View button, to get a list of packages
that would be updated.

But today with this version, I have a View named Pending that has a
lot of packages listed (about 100).
The Current column is empty for all of them.

I am confused.

I expected a few packages liste, with existing Current version and
newer version listed under the New column.

What am I missing?

Regards,
David

--
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: Setup.exe update confusion

[David Balažic]

On 5 August 2010 18:00, Larry Hall (Cygwin)
reply-to-list-only...@cygwin.com wrote:
 On 8/5/2010 11:42 AM, David Balažic wrote:

 Hi!

 I just downloaded and started Setup.exe (version 2.708).

 I have already Cygwin installed, I wnated just to update to newest state.

 So I clicked Next, until I got to the package selection.

 Before I used then to click the View button, to get a list of packages
 that would be updated.

 But today with this version, I have a View named Pending that has a
 lot of packages listed (about 100).

 Pending is the old Partial view.  It's been renamed.

Check.


 The Current column is empty for all of them.

 I am confused.

 I expected a few packages liste, with existing Current version and
 newer version listed under the New column.

 What am I missing?

 I don't think too much.  I ran setup.exe 2.708 and setup.exe 2.697.
 The same pages in each showed the same thing.  Although my list of
 updates was smaller, not all the packages listed had a current field.
 My list contained new dependencies for the packages being updated.
 If there really are no packages listed with a Current version, I'd
 say you're experiencing the result of setup.ini being updated with
 previously missing packages for packages you have already installed.

I started it again, and now the Pending view is empty.

The first time it had arj as the first package. I doubt anything depends on arj.

The first time I also tried different mirrors. With same result (lot
of packages in Pending).

Now I again tried 2 different mirrors and both show no packages Pending.

I did not install anything on the first occasion, I canceled the Setup.

I'm even more confused now...

Regards,
David

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

PCYMTNQREAIYR Re: Setup.exe update confusion

[David Balažic]

On 5 August 2010 18:37, Larry Hall (Cygwin)  wrote:
 On 8/5/2010 12:24 PM, David Balažic wrote:

 On 5 August 2010 18:00, Larry Hall (Cygwin)
   wrote:

  ^^
 http://cygwin.com/acronyms/#PCYMTNQREAIYR  Thanks.

Without concrete advice that link doesn't do much.
An average Joe has no idea what configuring means anyway, let alone
being able to do such a change.

For example, how do I do that in gmail?

I am an advanced user, but can't find anything related in Settings.

Regards,
David

--
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: PCYMTNQREAIYR Re: Setup.exe update confusion

[David Balažic]

On 5 August 2010 19:13, DePriest, Jason R. jrdepri...@gmail.com wrote:
 On Thu, Aug 5, 2010 at 11:51 AM, David Balažic  wrote:
 On 5 August 2010 18:37, Larry Hall (Cygwin)  wrote:
 On 8/5/2010 12:24 PM, David Balažic wrote:

 On 5 August 2010 18:00, Larry Hall (Cygwin)
   wrote:

  ^^
 http://cygwin.com/acronyms/#PCYMTNQREAIYR  Thanks.

 Without concrete advice that link doesn't do much.
 An average Joe has no idea what configuring means anyway, let alone
 being able to do such a change.

 For example, how do I do that in gmail?

 I am an advanced user, but can't find anything related in Settings.

 Regards,
 David

 In Gmail, I do it manually.  It only takes a few seconds.

 However, I did just submit an enhancement request for an option to
 auto-obfuscate email addresses in forwards and replies.

Well, if you post an URL to it, we can +1 it.


On the other side, if web archives are the problem, why not change them?
Some mail archive program have that feature.

--
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: MS-DOS path warning with maven

[David Balažic]

On 10 May 2010 22:40, Jeremy Bopp jer...@bopp.net wrote:
 On 5/10/2010 3:11 PM, David Balažic wrote:
 On 10 May 2010 20:52, Jeremy Bopp jer...@bopp.net wrote:
 What's the output when you run the following?

 $ sh -x $(which mvn) -version

 I attached it.

 I don't see the Cygwin warning message in that output.  What I did see
 in the output, though, tells me that there shouldn't be anything causing
 that message at all.

 Try running the following to see if it captures the warning message:

 $ sh -x $(which mvn) -version mvn.log 21

Attached, this time including the warning.

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

Bad Thread Prev links in list web archive

[David Balažic]

Hi!

The Thread Prev link in the mail list web archive does not work in some cases.

Example:
http://cygwin.com/ml/cygwin/2010-03/msg01033.html

Click Thread Next. (shows next message in thread)
Click Thread Next. (shows next message in thread)
Click Thread Prev. (shows the prev message)
Click Thread Prev. (see below)

You should arrive back at the first message, but instead a message
from another thread is displayed.

Regards,
David

--
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: MS-DOS path warning with maven

[David Balažic]

On 10 May 2010 22:28, Christopher Faylor
cgf-use-the-mailinglist-ple...@cygwin.com wrote:
 On Mon, May 10, 2010 at 10:11:33PM +0200, David Bala??ic wrote:
On 10 May 2010 20:52, Jeremy Bopp jer...@bopp.net wrote:
 What's the output when you run the following?

 $ sh -x $(which mvn) -version

I attached it.
Also the output of cygcheck -s -v -r  cygcheck.out

 Hmm.  All of this time I thought that maven was a package distributed
 with Cygwin.  After looking I should have checked
 http://cygwin.com/packages/ to see if that was true.

 It doesn't look like that is the case so it seems like this
 would be YA instance of check with the package provider rather
 than expecting people in the Cygwin list to know.

Sorry for the confusion.

The package is this:
http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.zip

I also posted on the maven-users list:
http://old.nabble.com/Maven-triggers-cygwin-warning-to28521741.html

Regards,
David

--
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: Bad Thread Prev links in list web archive

[David Balažic]

On 11 May 2010 14:23, Nellis, Kenneth kenneth.nel...@acs-inc.com wrote:
 From: David Balažic
 Sent: Tuesday, May 11, 2010 05:09
 To: cygwin@cygwin.com
 Subject: Bad Thread Prev links in list web archive

 Hi!

 The Thread Prev link in the mail list web archive does not work in
 some cases.
 ...
 Regards,
 David

 Actually, it looks like the initial Thread Next is the culprit,
 skipping from message 161201 to 161203. Thread Prev then allows
 one to see 161202.

Sorry, where do you see the numbers 161201... ?

I just opened all messages from that thread, then I opened the first
again and clicked the Thread Next link, until the last one.
All messages in the thread were displayed correctly. If I try to go
back using Thread Prev, I get lost.

It is the same with other threads: Thread Next works, Thread Prev
on the other hand does the same as Date Prev.

So Thread Prev behaves as Date Prev instead of going inside the
thread backwards.

Regards,
David

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

MS-DOS path warning with maven

[David Balažic]

Hi!

I have cygwin 1.7.5 (up to date as of now) on Windows XP Pro SP3 and
maven v 2.2.1.

When I start mvn from a shell (I use mintty running bash): i get a warning:


cygwin warning:
  MS-DOS style path detected: F:\winsux\prg\apache-maven-2.2.1/boot/
  Preferred POSIX equivalent is: /cygdrive/f/winsux/prg/apache-maven-2.2.1/boot/
  CYGWIN environment variable option nodosfilewarning turns off this warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames


I found it strange, since maven is cygwin aware and should use cygwin paths.

Is this some bug?

Regards,
David

PS: I use Sun JDK 1.6.0_20 as Java environment.

--
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: MS-DOS path warning with maven

[David Balažic]

On 10 May 2010 16:44, Jeremy Bopp jer...@bopp.net wrote:
 On 5/10/2010 4:21 AM, David Balažic wrote:
 Hi!

 I have cygwin 1.7.5 (up to date as of now) on Windows XP Pro SP3 and
 maven v 2.2.1.

 When I start mvn from a shell (I use mintty running bash): i get a warning:


 cygwin warning:
   MS-DOS style path detected: F:\winsux\prg\apache-maven-2.2.1/boot/
   Preferred POSIX equivalent is: 
 /cygdrive/f/winsux/prg/apache-maven-2.2.1/boot/
   CYGWIN environment variable option nodosfilewarning turns off this 
 warning.
   Consult the user's guide for more details about POSIX paths:
     http://cygwin.com/cygwin-ug-net/using.html#using-pathnames


 I found it strange, since maven is cygwin aware and should use cygwin paths.

 Is this some bug?

 I'm unable to reproduce your problem when running a simple mvn -version
 command.  After looking through the mvn script included with the Maven
 installation, I also can't see anywhere that script would directly
 attempt to use a Windows-style path where a POSIX style path would be
 required to avoid this warning.

 My best guess is that you are either defining the JAVACMD environment
 variable to point to a Cygwin program, defining JAVA_HOME to point to a
 Cygwin-based JRE/JDK, or have a Cygwin-based java.exe in your path.  In
 all of those cases, the mvn script will attempt to feed Windows-style
 paths to a Cygwin program, and that would likely trigger this warning.
 If that's not the problem, it could be that whatever target you're
 trying to run ultimately attempts to run some Cygwin program with a
 Windows-style path.  In all cases, Cygwin is functioning as designed.

 To diagnose the problem further, you need to first eliminate all of your
 build logic as the cause.  Running mvn -version as I did should do that
 for you.  Then make sure that you're not somehow causing a Cygwin
 program to be used in place of Sun's java.exe as noted above.  If you do
 that and still see this warning, then you need to talk with the Maven
 developers and/or the developers of whatever Maven plugins you're using.

mvn -version also gives the message.


$ which -a java
/cygdrive/c/WINDOWS/system32/java


$ set | grep JAVA
JAVA_HOME='C:\Program Files\Java\jdk1.6.0_20'

I'm not caiming there is somethng wrong with cygwin, jut find it
surprising to get this warning with a cygwin-aware  program (mvn).

Regards,
David

--
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: MS-DOS path warning with maven

[David Balažic]

On 10 May 2010 20:52, Jeremy Bopp jer...@bopp.net wrote:
 What's the output when you run the following?

 $ sh -x $(which mvn) -version

I attached it.
Also the output of cygcheck -s -v -r  cygcheck.out

Regards,
David


cygcheck.out
Description: Binary data


outwhich
Description: Binary data
--
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: MS-DOS path warning with maven

[David Balažic]

On 10 May 2010 20:52, Jeremy Bopp jer...@bopp.net wrote:
 The mvn script also sources /etc/mavenrc and ~/.mavenrc files if they
 exist, so it's possible that what you're seeing is the result of
 something running in one of them.  I noticed that the path in the

I don't have these two files.

David

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

setup.exe download has no Content-Length header

[David Balažic]

Hi!

When downloading http://www.cygwin.com/setup.exe with Firefox, the
server sends no Content-Length header,
so the download manager can not show a percentage progress. Here are
the headers captured with
the Live HTTP Headers plugin:

http://www.cygwin.com/setup.exe

GET /setup.exe HTTP/1.1
Host: www.cygwin.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.cygwin.com/

HTTP/1.1 200 OK
Date: Sat, 17 Apr 2010 19:51:41 GMT
Server: Apache/2.0.52 (Red Hat)
Last-Modified: Thu, 08 Apr 2010 15:55:13 GMT
Etag: 18e1397-a6213-b43f1a40
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Cache-Control: max-age=0
Expires: Sat, 17 Apr 2010 19:51:41 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/octet-stream

--
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: mintty - char encoding problems

[David Balažic]

Hi!

I have again LANG=SL  in  minTTY.

I also see LANG=SL in cmd.exe.

No idea where it came from.

Info:
Regional: standards and formats: Slovenian; Location: United States;
Languages (kbd): English


I'll post more as I discover things.

Regards,
David

--
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: mintty - char encoding problems

[David Balažic]

On 21 February 2010 07:10, Andy Koppe andy.ko...@gmail.com wrote:
 David Balažic:
 I'm puzzled by that, because the standards and formats setting
 shouldn't have any effect on LANG, at least as far as mintty and
 Cygwin are concerned. Any idea how it might have got set to SL?

 As I already mentioned, it is a fresh cygwin install.
 And since the problem is triggered by a simple change in the system
 prefs, anyone onterested can try it ;-)

 Gee, thanks. No, I can't reproduce it.

 Neither mintty nor Cygwin set LANG based on the Regional and Languages
 section, nor does Windows itself. This means something else set it to
 SL. Is there any other Unixish software on your machine that might
 be doing that? MS's Services for Unix perhaps? Emacs?

 I understand you're no longer interested in this since you've solved
 your problem, but it would nevertheless be good to know what happened
 in case others hit this.

I'm _always_ interested in killing a bug ;-)

 - LANG is not set in Windows (checked by set and echo %LANG% in
command prompt)
 - if I set Standards and formats : back to Slovenian, I still have
LANG=C.UTF-8 !!!
  I will try if there is a difference if I log off and back on, or reboot
 - I don't see SFU in Add or Remove programs, neither is there a C:\SFU folder
 - I have gvim 7.2, and as mentioned, an older version of cygwin
(1.5.25), it has no LANG variable defined when started (Cygwin Bash
Shell)

Regards,
David

--
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: mintty - char encoding problems

[David Balažic]

On 20 February 2010 13:23, Andy Koppe andy.ko...@gmail.com wrote:
 David Balažic:
 A mismatch of Cygwin's charset and mintty's charset, probably. What
 versions of Cygwin and mintty are you using? What are the values of
 LC_ALL, LC_CTYPE and LANG? Is anything set in the Charset (or
 Codepage) field on the Text pane of mintty's options?

  Cygwin DLL version info:
        DLL version: 1.7.1
 mintty               0.5.7-1

 $LANG is SL ,  LC_* are undefined

 The mintty Text settings are empty.

 Right. As Thomas already pointed out, SL is an invalid locale
 setting. In this case, Cygwin programs use the C locale, which in
 1.7.1. implies UTF-8. Mintty, on the other hand, falls back to the
 system's ANSI codepage, with less than pretty results.

 Not quite a bug, since you can't expect anything non-ASCII to work
 correctly with an invalid locale setting, but nevertheless I've now
 changed mintty to fall back to UTF-8.


 As mentioned, this is a fresh install and 99,9% of settings are at default.

 Windows Regional settings are:
 Standards and formats : Slovenian
 Location: United States
 Input Language/Keyborad layout: US English


 Aha, the other account has:
 Standards and formats : English (US)

 I changed it on this account too and now it works.

 $LANG is now C.UTF-8

 I'm puzzled by that, because the standards and formats setting
 shouldn't have any effect on LANG, at least as far as mintty and
 Cygwin are concerned. Any idea how it might have got set to SL?

 In any case, the easy way to set locale and charset in mintty is via
 the Text options. This will also set up LANG accordingly in newly
 started sessions.

As I already mentioned, it is a fresh cygwin install.
There is alreadt an old, pre-1.7 cygwin setup, but according to post
here, it should not matter.

And since the problem is triggered by a simple change in the system
prefs, anyone onterested can try it ;-)

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

mintty - char encoding problems

[David Balažic]

Hi!

I have few days old setup of cygwin on WinXP.
I also installed mintty.

I worked fine on one user account, which is a member of the
Administrators group.

Today I started mintty under another, not admin, user, and got this:

»./.bashrc« - »/home/work//.bashrc«
»./.bash_profile« - »/home/work//.bash_profile«
»./.inputrc« - »/home/work//.inputrc«

I also can not type certain non-ascii chars, that worked fine in the
first user, like čšž.
Now they appear on the bach command line as c ( š and ž don't appear at all).

Any idea what is wrong?

Regards,
David

--
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: mintty - char encoding problems

[David Balažic]

On 19 February 2010 21:00, Andy Koppe andy.ko...@gmail.com wrote:
 On 19 February 2010 19:39, David Balažic:
 Hi!

 I have few days old setup of cygwin on WinXP.
 I also installed mintty.

 I worked fine on one user account, which is a member of the
 Administrators group.

 Today I started mintty under another, not admin, user, and got this:

 »./.bashrc« - »/home/work//.bashrc«
 »./.bash_profile« - »/home/work//.bash_profile«
 »./.inputrc« - »/home/work//.inputrc«

 I also can not type certain non-ascii chars, that worked fine in the
 first user, like čšž.
 Now they appear on the bach command line as c ( š and ž don't appear at all).

 Any idea what is wrong?

 A mismatch of Cygwin's charset and mintty's charset, probably. What
 versions of Cygwin and mintty are you using? What are the values of
 LC_ALL, LC_CTYPE and LANG? Is anything set in the Charset (or
 Codepage) field on the Text pane of mintty's options?

 Cygwin DLL version info:
DLL version: 1.7.1
mintty   0.5.7-1

$LANG is SL ,  LC_* are undefined

The mintty Text settings are empty.

As mentioned, this is a fresh install and 99,9% of settings are at default.

Windows Regional settings are:
Standards and formats : Slovenian
Location: United States
Input Language/Keyborad layout: US 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: mintty - char encoding problems

[David Balažic]

On 20 February 2010 00:08, David Balažic xerc...@gmail.com wrote:
 On 19 February 2010 21:00, Andy Koppe andy.ko...@gmail.com wrote:
 On 19 February 2010 19:39, David Balažic:
 Hi!

 I have few days old setup of cygwin on WinXP.
 I also installed mintty.

 I worked fine on one user account, which is a member of the
 Administrators group.

 Today I started mintty under another, not admin, user, and got this:

 »./.bashrc« - »/home/work//.bashrc«
 »./.bash_profile« - »/home/work//.bash_profile«
 »./.inputrc« - »/home/work//.inputrc«

 I also can not type certain non-ascii chars, that worked fine in the
 first user, like čšž.
 Now they appear on the bach command line as c ( š and ž don't appear at 
 all).

 Any idea what is wrong?

 A mismatch of Cygwin's charset and mintty's charset, probably. What
 versions of Cygwin and mintty are you using? What are the values of
 LC_ALL, LC_CTYPE and LANG? Is anything set in the Charset (or
 Codepage) field on the Text pane of mintty's options?

  Cygwin DLL version info:
        DLL version: 1.7.1
 mintty               0.5.7-1

 $LANG is SL ,  LC_* are undefined

 The mintty Text settings are empty.

 As mentioned, this is a fresh install and 99,9% of settings are at default.

 Windows Regional settings are:
 Standards and formats : Slovenian
 Location: United States
 Input Language/Keyborad layout: US English


Aha, the other account has:
Standards and formats : English (US)

I changed it on this account too and now it works.
$LANG is now C.UTF-8

It smells like a bug. A non US locale should not disable UTF-8, or?

Regards,
David

--
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: Wrong setup.exe on http://www.cygwin.com/

[David Balažic]

On 3 February 2010 13:46, Dave Korn dave.korn.cyg...@googlemail.com wrote:
 On 03/02/2010 08:16, Morten Kjærulff wrote:
 Hi,

 I tried downloading http://www.cygwin.com//setup.exe (note 2 //), and
 got 2.680. http://www.cygwin.com/setup.exe is still 2.674 for me.

  You found a clever way to trick the caching proxy that's messing things up
 for you!

  Another thing that often works is to use a public open-proxy server to
 redirect the request for you; it only takes seconds to google a few up.

Another simple trick that usually works is to append
?some-random-stuff to the url, like:

http://www.cygwin.com/setup.exego_away_proxy!

Regards,
David

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

Parallel use of v1.7.1 and v1.5.x ?

[David Balažic]

Hi!

I already have the old version (v1.5.25) of cygwin installed and I
wonder if is it safe (supported)  to run v1.7.1 at the same time ?

So I can evaluate v1.7.1 and eventually remove the other.

I know the FAQ says multiple setups ov v1.7. are possible, but it does
not mentiob v1.5.

Regards,
David

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

Error during upgrade/X11 install

[David Balažic]

Hi!

I had a base cygwin installation* on WinXP-pro-SP2.
Then I downloaded the latest setup.exe,
selected xorg-x11-base and clicked NEXT...

During install I got an error dialog :

sh.exe - Unable To Locate Component

This application has failed to start because cygwin1.dll was not
found. Re-installing the application may fix this problem.


Everything appeared to work fine both before and after this update,
so I am posting this more as something for developers to work on,
if they think this is a bug.

Regards,
David

* - a fresh install from a few weeks ago



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