Inode number and file size problems in version 3.2.1

Inode number and file size problems in version 3.2.1

[Ruurd Beerstra]

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

Re: Inode number and file size problems in version 3.2.1

[Ken Brown]

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

Ken

Re: Inode number and file size problems in version 3.2.1

[Brian Inglis]

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

Re: Inode number and file size problems in version 3.2.1

[Ken Brown]

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

Re: Inode number and file size problems in version 3.2.1

[Ruurd Beerstra]

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

Re: Inode number and file size problems in version 3.2.1

[Ken Brown]

[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

Re: Inode number and file size problems in version 3.2.1

[Corinna Vinschen]

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

Re: Inode number and file size problems in version 3.2.1

[Ken Brown]

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