DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA74A3861C54
Subject: Re: Inode number and file size problems in version 3.2.1
To: Ken Brown <kbrown@cornell.edu>, cygwin@cygwin.com
References: <0cbd1744-ada6-d7b8-dbf5-5617a41470fb@wxs.nl>
 <8206027a-a5b5-298f-85bc-01a4a7c02b58@cornell.edu>
 <244fa3f1-08a9-eeb1-6ee0-b0d1c6033ab5@cornell.edu>
Message-ID: <0d901ab3-0e3c-5e27-5d2e-6617466837de@wxs.nl>
Date: Tue, 6 Jul 2021 11:15:52 +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
In-Reply-To: <244fa3f1-08a9-eeb1-6ee0-b0d1c6033ab5@cornell.edu>
Content-Language: en-US
Precedence: list
From: Ruurd Beerstra via Cygwin <cygwin@cygwin.com>
Reply-To: Ruurd Beerstra <ruurdb@wxs.nl>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

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