From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cpsmtpb-ews06.kpnxchange.com (cpsmtpb-ews06.kpnxchange.com [213.75.39.9]) by sourceware.org (Postfix) with ESMTP id 3322A3865470 for ; Thu, 1 Jul 2021 12:15:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3322A3865470 Received: from cpsps-ews23.kpnxchange.com ([10.94.84.189]) by cpsmtpb-ews06.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Thu, 1 Jul 2021 14:15:04 +0200 X-Brand: 7abm2Q== X-KPN-SpamVerdict: e1=0;e2=0;e3=0;e4=;e6=(e1=10;e3=10;e2=11;e4=10;e6=1 0);EVW:White;BM:NotScanned;FinalVerdict:Clean X-CMAE-Analysis: v=2.4 cv=PdOcOgtd c=1 sm=1 tr=0 ts=60ddb1c8 cx=a_idp_e a=4/rmT19p7yX2nqNQQg5uwQ==:117 a=TOtYYj/GSYWBgm6f19gFrg==:17 a=h8ePZlyUMksA:10 a=IkcTkHD0fZMA:10 a=e_q4qTt1xDgA:10 a=xcQg3-xCUMWoe_1AWFoA:9 a=QEXdDO2ut3YA:10 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.44]) by cpsps-ews23.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 1 Jul 2021 14:15:04 +0200 X-Originating-IP: 77.169.151.208 Received: from [10.0.0.28] (77-169-151-208.fixed.kpn.net [77.169.151.208]) by smtp.kpnmail.nl (Halon) with ESMTP id f7774256-da65-11eb-86a8-005056abf0db; Thu, 01 Jul 2021 14:15:04 +0200 (CEST) To: cygwin@cygwin.com From: Ruurd Beerstra Subject: Inode number and file size problems in version 3.2.1 Message-ID: <0cbd1744-ada6-d7b8-dbf5-5617a41470fb@wxs.nl> Date: Thu, 1 Jul 2021 14:15:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB X-OriginalArrivalTime: 01 Jul 2021 12:15:04.0524 (UTC) FILETIME=[B95288C0:01D76E72] X-RcptDomain: cygwin.com X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 12:15:12 -0000 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=20 and check. I use flex/bison, ctags, make, gawk, grep and a bunch of other Cygwin=20 utilities. I bought a new PC and decided to to a clean-install of Cygwin to make=20 sure I had the latest version of everything. I ran into various problems, which after checking I found to be bugs in=20 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=3D|^MAKE=3D" makefile | sed -e "s/RUNCMD=3D//" -e=20 "s/^MAKE=3D/set &/" > %TEMP%\extra.bat would hang. So would stuff like "cat ... | sort | uniq" style commands=20 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=3D$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=20 "allfcn.f", which contains unwanted \r characters which are removed by=20 the 'tr' command. This has worked for 20+ years this way. The 'mv' complains that the=20 source and target are the same. Using ls -i=C2=A0 I see this weirdness: i:\ivt\work>ls -li allfcn* 281474977027142 -rw-r--r--+ 1 ruurd ruurd 8192 Jul=C2=A0 1 12:30 allfcn.f= 281474977027142 -rw-r--r--+ 1 ruurd ruurd 8192 Jul=C2=A0 1 12:30 allfcn.f= =2Etmp The inode numbers are the same!=C2=A0 Which is why it thinks the files ar= e=20 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=20 (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 =C2=A0=C2=A0 echo "The following keywords are NOT documented in doc/all*= =2Ee:" =C2=A0=C2=A0 cat undoc.keywords =C2=A0=C2=A0 echo "See file undoc.keywords" =C2=A0=C2=A0 Failure fi So I look at the file: i:\ivt>ls -l undoc.keywords -rw-r--r--+ 1 ruurd ruurd 8192 Jul=C2=A0 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 =C2=A0Volume in drive I is Windows =C2=A0Volume Serial Number is 2237-3266 =C2=A0Directory of i:\ivt 01/07/2021=C2=A0 13:11=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 undoc.keywords =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 1 File(s)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 0 bytes =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0 Dir(s)=C2=A0 383.936.823.296 bytes free It IS zero bytes!=C2=A0 But Cygwin shows it as 8KB, which is why the "-s"= =20 operator says the file is not empty. i:\ivt>stat undoc.sh =C2=A0 File: undoc.sh =C2=A0 Size: 8192=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Blocks: 8=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= IO Block: 65536 regular file Device: 22373266h/574042726d=C2=A0=C2=A0=C2=A0 Inode: 281474977027142=C2=A0= Links: 1 Access: (0700/-rwx------)=C2=A0 Uid: (197609/=C2=A0=C2=A0 ruurd)=C2=A0=C2= =A0 Gid: (197609/=C2=A0=C2=A0 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 =C2=A0Birth: 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=20 c:\Cygwin64.old) and use the commands from there on the same file: i:\ivt>stat undoc.keywords =C2=A0 File: undoc.keywords =C2=A0 Size: 8192=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Blocks: 8=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= IO Block: 65536 regular file Device: 22373266h/574042726d=C2=A0=C2=A0=C2=A0 Inode: 281474977027142=C2=A0= Links: 1 Access: (0644/-rw-r--r--)=C2=A0 Uid: (197609/=C2=A0=C2=A0 ruurd)=C2=A0=C2= =A0 Gid: (197609/=C2=A0=C2=A0 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 =C2=A0Birth: 2021-06-30 13:59:31.554377500 +0200 i:\ivt>c:\cygwin64.old\bin\stat undoc.keywords =C2=A0 File: undoc.keywords =C2=A0 Size: 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Blocks: 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 IO Block: 65536 regular=20 empty file Device: 22373266h/574042726d=C2=A0=C2=A0=C2=A0 Inode: 1970324837303561=C2= =A0 Links: 1 Access: (0644/-rw-r--r--)=C2=A0 Uid: (197609/=C2=A0=C2=A0 ruurd)=C2=A0=C2= =A0 Gid: (197609/=C2=A0=C2=A0 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 =C2=A0Birth: 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=20 consistently reports correct times, size and inode number. A quick test=20 shows that the 'ls' command (I assume caused by the underlying stat(2)=20 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. =C2=A0=C2=A0=C2=A0 Help/pointers appreciated, =C2=A0=C2=A0=C2=A0 Ruurd Beerstra