DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3322A3865470
To: cygwin AT cygwin DOT com
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-Language: en-GB
From: Ruurd Beerstra via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Ruurd Beerstra <ruurdb AT wxs DOT nl>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

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

     Help/pointers appreciated,
     Ruurd Beerstra


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