Re: Inode number and file size problems in version 3.2.1

[Ruurd Beerstra <ruurdb@wxs.nl>]

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