Re: Inode number and file size problems in version 3.2.1
On 7/7/2021 4:50 AM, Corinna Vinschen via Cygwin wrote: On Jul 6 11:53, Ken Brown via Cygwin wrote: [Please don't top-post on this list. Thanks.] On 7/6/2021 5:15 AM, Ruurd Beerstra wrote: Hi, I missed those question - sorry. This ping is the first I saw i response to my question. That was my guess and was the reason I added you to the CC on the ping and on this message. (The custom on this list is *not* to do that.) The drive "i:" is a simple "subst": C:\>subst I:\: => C:\users\ruurd C:\> But, to my surprise, that actually causes the problem! The cygwin64.broken is the Cygwin version with the problem. If I use the SUBST drive, I get the wrong dates, sizes and inodes. When I use it directly, it is OK! [...] I think I see the commit that introduced this bug, and Corinna just reverted it. I'll try and use the snapshot this evening. Or you could wait until Corinna has a chance to make a new snapshot that includes what I think is the fix. Ken Just creating one... I was able to reproduce the OP's problem with the 20210426 snapshot, and I can confirm that it's fixed in the latest snapshot (and in the current git HEAD). Ruurd, thanks for the report. Ken -- 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: Inode number and file size problems in version 3.2.1
On Jul 6 11:53, Ken Brown via Cygwin wrote: > [Please don't top-post on this list. Thanks.] > > On 7/6/2021 5:15 AM, Ruurd Beerstra wrote: > > Hi, > > > > I missed those question - sorry. This ping is the first I saw i response > > to my question. > > That was my guess and was the reason I added you to the CC on the ping and > on this message. (The custom on this list is *not* to do that.) > > > The drive "i:" is a simple "subst": > > > > C:\>subst > > I:\: => C:\users\ruurd > > > > C:\> > > > > But, to my surprise, that actually causes the problem! The > > cygwin64.broken is the Cygwin version with the problem. > > If I use the SUBST drive, I get the wrong dates, sizes and inodes. When > > I use it directly, it is OK! > > [...] > > I think I see the commit that introduced this bug, and Corinna just reverted > it. > > > I'll try and use the snapshot this evening. > > Or you could wait until Corinna has a chance to make a new snapshot that > includes what I think is the fix. > > Ken Just creating one... 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: Inode number and file size problems in version 3.2.1
[Please don't top-post on this list. Thanks.] On 7/6/2021 5:15 AM, Ruurd Beerstra wrote: Hi, I missed those question - sorry. This ping is the first I saw i response to my question. That was my guess and was the reason I added you to the CC on the ping and on this message. (The custom on this list is *not* to do that.) The drive "i:" is a simple "subst": C:\>subst I:\: => C:\users\ruurd C:\> But, to my surprise, that actually causes the problem! The cygwin64.broken is the Cygwin version with the problem. If I use the SUBST drive, I get the wrong dates, sizes and inodes. When I use it directly, it is OK! [...] I think I see the commit that introduced this bug, and Corinna just reverted it. I'll try and use the snapshot this evening. Or you could wait until Corinna has a chance to make a new snapshot that includes what I think is the fix. Ken -- 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: Inode number and file size problems in version 3.2.1
Hi, I missed those question - sorry. This ping is the first I saw i response to my question. The drive "i:" is a simple "subst": C:\>subst I:\: => C:\users\ruurd C:\> But, to my surprise, that actually causes the problem! The cygwin64.broken is the Cygwin version with the problem. If I use the SUBST drive, I get the wrong dates, sizes and inodes. When I use it directly, it is OK! I've had the SUBST for many years, as a quick way to get to wherever the source lives. C:\Users\ruurd\ivt>c:\cygwin64.broken\bin\ls -li win* 281474977247364 -rwx--+ 1 ruurd ruurd 0 Feb 5 2014 win-mac.h 281474977247365 -rwx--+ 1 ruurd ruurd 2969 Apr 12 15:23 winnoise.c 281474977247366 -rwx--+ 1 ruurd ruurd 9037 Oct 25 2017 winsecur.c 281474977247367 -rwx--+ 1 ruurd ruurd 2480 Oct 25 2017 winsecur.h 281474977247368 -rwx--+ 1 ruurd ruurd 61009 Dec 6 2020 winstatus.c 281474977247369 -rwx--+ 1 ruurd ruurd 18292 Feb 8 2020 winwords.h C:\Users\ruurd\ivt>i: i:\ivt>c:\cygwin64.broken\bin\ls -li win* 281474977027142 -rwx--+ 1 ruurd ruurd 12288 Jul 6 10:36 win-mac.h 281474977027142 -rwx--+ 1 ruurd ruurd 12288 Jul 6 10:36 winnoise.c 281474977027142 -rwx--+ 1 ruurd ruurd 12288 Jul 6 10:36 winsecur.c 281474977027142 -rwx--+ 1 ruurd ruurd 12288 Jul 6 10:36 winsecur.h 281474977027142 -rwx--+ 1 ruurd ruurd 12288 Jul 6 10:36 winstatus.c 281474977027142 -rwx--+ 1 ruurd ruurd 12288 Jul 6 10:36 winwords.h I'll try and use the snapshot this evening. Thanks, Ruurd On 5-7-2021 20:19, Ken Brown wrote: On 7/1/2021 12:21 PM, Ken Brown via Cygwin wrote: On 7/1/2021 8:15 AM, Ruurd Beerstra via Cygwin wrote: [...] I found a patch (cygwin1-20210426.dll) with an updated cygwin1.dll. That fixed the hangs. [...] Note the wrong (changing) times when I use the current 'stat' (the first output is not the same as the 2nd one), while the old version consistently reports correct times, size and inode number. A quick test shows that the 'ls' command (I assume caused by the underlying stat(2) call) reports the same inode number for ALL files. It also reports either a size of "0" or 8192 for ALL files. Can you tell us something about i:\ivt so that someone could try to reproduce the problem? What kind of drive is i:? Does the path "i:\ivt" by any chance involve native symlinks or junctions? Ping? Can you answer the questions? If there's a bug in the 20210426 snapshot, we'd like to fix it. But first it would be good if you would test the most recent snapshot (20210507), available at https://cygwin.com/snapshots/, to see if it's already been fixed. Thanks. Ken -- 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: Inode number and file size problems in version 3.2.1
On 7/1/2021 12:21 PM, Ken Brown via Cygwin wrote: On 7/1/2021 8:15 AM, Ruurd Beerstra via Cygwin wrote: [...] I found a patch (cygwin1-20210426.dll) with an updated cygwin1.dll. That fixed the hangs. [...] Note the wrong (changing) times when I use the current 'stat' (the first output is not the same as the 2nd one), while the old version consistently reports correct times, size and inode number. A quick test shows that the 'ls' command (I assume caused by the underlying stat(2) call) reports the same inode number for ALL files. It also reports either a size of "0" or 8192 for ALL files. Can you tell us something about i:\ivt so that someone could try to reproduce the problem? What kind of drive is i:? Does the path "i:\ivt" by any chance involve native symlinks or junctions? Ping? Can you answer the questions? If there's a bug in the 20210426 snapshot, we'd like to fix it. But first it would be good if you would test the most recent snapshot (20210507), available at https://cygwin.com/snapshots/, to see if it's already been fixed. Thanks. Ken -- 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: Inode number and file size problems in version 3.2.1
On 2021-07-01 06:15, Ruurd Beerstra via Cygwin wrote:
I am a long-time user and fan of Cygwin.
I use it in a complex build environment of my IVT SSH terminal emulator,
some 300.000 lines of C-code with lots of little shell-scripts to build
and check.
I use flex/bison, ctags, make, gawk, grep and a bunch of other Cygwin
utilities.
I bought a new PC and decided to to a clean-install of Cygwin to make
sure I had the latest version of everything.
Your new PC probably has a newer version of Windows, possibly new MS
software, and new AV or other utilities, which could be in BLODA: what
are your old and new hardware types and Window editions/versions/etc?
You can check for BLODA by running cygcheck or ldd against programs with
issues, e.g. cygcheck grep make sed cat sort uniq, and look for
non-standard Windows and Cygwin DLLs whoch could indicate interference.
That also implies that you had not being keeping your environment up to
date with setup -g?
I ran into various problems, which after checking I found to be bugs in
Cygwin (a first for me). So I'm reporting them here.
The first problem I ran into was that multiple-pipe commands would hang.
A command like this in a CMD file:
grep -E "^RUNCMD=|^MAKE=" makefile | sed -e "s/RUNCMD=//" -e
"s/^MAKE=/set &/" > %TEMP%\extra.bat
would hang. So would stuff like "cat ... | sort | uniq" style commands
that I use a lot.
I found a patch (cygwin1-20210426.dll) with an updated cygwin1.dll. That
fixed the hangs.
My 'uname -r' now reports 3.2.1s(0.340/5/3)
But then one of my scripts ran into a weird problem:
mv: 'allfcn.f.tmp' and 'allfcn.f' are the same file
gmake: *** [../make.w32:438: allfcn.f] Error 1
The inode numbers are the same! Which is why it thinks the files are
the same. Using 'cmp' on them tells me they differ, though.
So I insert an 'rm' command of the TMP file and that problem goes away
(though it didn't sit well with me that the file size is exactly 8KB for
both files, as reported by ls).
Hmm: Same 8KB again? That file is supposed to be 0 bytes! Check with DIR:
It IS zero bytes! But Cygwin shows it as 8KB, which is why the "-s"
operator says the file is not empty.
Hmm. Again, the EXACT same inode number as with the earlier problem, the
same 8KB size.
I restored my original Cygwin setup from the old laptop (as
c:\Cygwin64.old) and use the commands from there on the same file:
Note the wrong (changing) times when I use the current 'stat' (the first
output is not the same as the 2nd one), while the old version
consistently reports correct times, size and inode number. A quick test
shows that the 'ls' command (I assume caused by the underlying stat(2)
call) reports the same inode number for ALL files.
It also reports either a size of "0" or 8192 for ALL files.
Am I missing some updated DLL?
For now, I've gone back to the older version, which works fine.
Have you checked the new install /var/log/setup.log{,.full} to see if
there were any anomalies, and rerun setup -g to fix any issues?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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: Inode number and file size problems in version 3.2.1
On 7/1/2021 8:15 AM, Ruurd Beerstra via Cygwin wrote: Hi, I am a long-time user and fan of Cygwin. I use it in a complex build environment of my IVT SSH terminal emulator, some 300.000 lines of C-code with lots of little shell-scripts to build and check. I use flex/bison, ctags, make, gawk, grep and a bunch of other Cygwin utilities. I bought a new PC and decided to to a clean-install of Cygwin to make sure I had the latest version of everything. I ran into various problems, which after checking I found to be bugs in Cygwin (a first for me). So I'm reporting them here. The first problem I ran into was that multiple-pipe commands would hang. A command like this in a CMD file: grep -E "^RUNCMD=|^MAKE=" makefile | sed -e "s/RUNCMD=//" -e "s/^MAKE=/set &/" > %TEMP%\extra.bat would hang. So would stuff like "cat ... | sort | uniq" style commands that I use a lot. I found a patch (cygwin1-20210426.dll) with an updated cygwin1.dll. That fixed the hangs. My 'uname -r' now reports 3.2.1s(0.340/5/3) But then one of my scripts ran into a weird problem: mv: 'allfcn.f.tmp' and 'allfcn.f' are the same file gmake: *** [../make.w32:438: allfcn.f] Error 1 This is produced by this bit of code: gawk -F~ -v outfile=$2 -f ../tools/format.awk tr -d '\r' < $2 > $2.tmp mv $2.tmp $2 Where $2 is "alfcn.f". The GAWK produces a nicely formatted file "allfcn.f", which contains unwanted \r characters which are removed by the 'tr' command. This has worked for 20+ years this way. The 'mv' complains that the source and target are the same. Using ls -i I see this weirdness: i:\ivt\work>ls -li allfcn* 281474977027142 -rw-r--r--+ 1 ruurd ruurd 8192 Jul 1 12:30 allfcn.f 281474977027142 -rw-r--r--+ 1 ruurd ruurd 8192 Jul 1 12:30 allfcn.f.tmp The inode numbers are the same! Which is why it thinks the files are the same. Using 'cmp' on them tells me they differ, though. So I insert an 'rm' command of the TMP file and that problem goes away (though it didn't sit well with me that the file size is exactly 8KB for both files, as reported by ls). But then the build complained again: The following keywords are NOT documented in doc/all*.e: See file undoc.keywords gmake: *** [../make.w32:272: ivt.exe] Error 1 That is produced by this bit of code which warns me if I introduce a new feature in IVT without documenting it: if [[ -s undoc.keywords ]] then echo "The following keywords are NOT documented in doc/all*.e:" cat undoc.keywords echo "See file undoc.keywords" Failure fi So I look at the file: i:\ivt>ls -l undoc.keywords -rw-r--r--+ 1 ruurd ruurd 8192 Jul 1 13:05 undoc.keywords Hmm: Same 8KB again? That file is supposed to be 0 bytes! Check with DIR: i:\ivt>dir undoc.keywords Volume in drive I is Windows Volume Serial Number is 2237-3266 Directory of i:\ivt 01/07/2021 13:11 0 undoc.keywords 1 File(s) 0 bytes 0 Dir(s) 383.936.823.296 bytes free It IS zero bytes! But Cygwin shows it as 8KB, which is why the "-s" operator says the file is not empty. i:\ivt>stat undoc.sh File: undoc.sh Size: 8192 Blocks: 8 IO Block: 65536 regular file Device: 22373266h/574042726d Inode: 281474977027142 Links: 1 Access: (0700/-rwx--) Uid: (197609/ ruurd) Gid: (197609/ ruurd) Access: 2021-07-01 13:12:46.247988400 +0200 Modify: 2021-07-01 13:05:55.035592600 +0200 Change: 2021-07-01 13:05:55.035592600 +0200 Birth: 2021-06-30 13:59:31.554377500 +0200 Hmm. Again, the EXACT same inode number as with the earlier problem, the same 8KB size. I restored my original Cygwin setup from the old laptop (as c:\Cygwin64.old) and use the commands from there on the same file: i:\ivt>stat undoc.keywords File: undoc.keywords Size: 8192 Blocks: 8 IO Block: 65536 regular file Device: 22373266h/574042726d Inode: 281474977027142 Links: 1 Access: (0644/-rw-r--r--) Uid: (197609/ ruurd) Gid: (197609/ ruurd) Access: 2021-07-01 13:58:23.261901700 +0200 Modify: 2021-07-01 13:43:34.833286000 +0200 Change: 2021-07-01 13:43:34.833286000 +0200 Birth: 2021-06-30 13:59:31.554377500 +0200 i:\ivt>c:\cygwin64.old\bin\stat undoc.keywords File: undoc.keywords Size: 0 Blocks: 0 IO Block: 65536 regular empty file Device: 22373266h/574042726d Inode: 1970324837303561 Links: 1 Access: (0644/-rw-r--r--) Uid: (197609/ ruurd) Gid: (197609/ ruurd) Access: 2021-07-01 13:11:03.478267900 +0200 Modify: 2021-07-01 13:11:03.478267900 +0200 Change: 2021-07-01 13:11:03.478267900 +0200 Birth: 2021-07-01 13:06:51.255125100 +0200 Note the wrong (changing) times when I use the current 'stat' (the first output is not the same as the 2nd one), while the old version consistently reports correct times, size and inode number. A quick test shows that the 'ls' command (I assume caused by the underlying stat(2) call) reports the same inode number for ALL files. It
