DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 51EBPGTo1537620
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 51EBPGTo1537620
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=Rqrnfp46
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 70534385842A
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1739532314;
	bh=MC5ycnhuSJWeWH+9AKcBgdCY1Wu/0Tg/hv7S1X7IBXw=;
	h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=Rqrnfp46+SPdRlUjkuj//K82+Q0OqiS/RT8Y5f1kZorIIsfaxB3K863nDqQ2hzSNc
	gFCxoDSIu968DQd3U6YMJnQNzstDJhyqPpY4Ub7tf1fNElGLT+PmZz4SiOtYctBMe4
	9qzoVw7uOak3a6SfU4bhnJkrswW7g9bucnXKtWZU=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org C9F963858C2B
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org C9F963858C2B
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739532277; cv=none;
	b=CGbBTLpHdoedLSxaapQui4HoS0segh5ZLVjoAjYwGlEeZSc22fx74E66IG73gPwxbetxMPkGLIJZrL2Nd4vAIuGvVAUefrx8d7IzRFXOu4RA1tl0EN4O1Poxjb3obruGHFCUKWjuVfV8rpnTvLA4r1RD4Xc9Q2lSHM2vGs+WRu4=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1739532277; c=relaxed/simple;
	bh=VBLyxSVQX+dzo8uRnixMJ5WIX/AzpUFXnZRts7bXx6Y=;
	h=Subject:To:From:Message-ID:Date:MIME-Version;
	b=iq99WyruZNjmESRx0Tla9QW3BQ+ZOPA9H8abEjrCBvoiLmiKE72S7tPI2TQ3PIZqZtOiaF1NB07uilWRVjVLMAGHSUb389uPQjcUJHMdwoa0kQsMI3ssfl7ueK2XUK7TX5eQ7RJbJPrOfvGdVvwwIHXZ9BxTLUMZR0AupekPVe8=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org C9F963858C2B
Subject:	SEEK_DATA should fail at EOF (was: coreutils-9.6-1 (TEST): cp:
	infinite SEEK_SET/DATA/HOLE loop if file is compressed)
To:	cygwin AT cygwin DOT com
References:	<614771e9-592c-6154-d56d-13842b6fc6ac AT t-online DOT de>
Message-ID:	<5ccdf4be-4e4b-1846-9fd6-cba29c9dbb11@t-online.de>
Date:	Fri, 14 Feb 2025 12:24:14 +0100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101
	SeaMonkey/2.53.20
MIME-Version:	1.0
In-Reply-To:	<614771e9-592c-6154-d56d-13842b6fc6ac@t-online.de>
X-TOI-EXPURGATEID:	150726::1739532254-32FFAAA5-47E90548/10/3626336762 SUSPECT
	URL
X-TOI-MSGID:	b260e322-5c9c-4748-8c63-ac672e86d555
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Christian Franke via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Christian Franke <Christian DOT Franke AT t-online DOT de>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 51EBPGTo1537620

Christian Franke via Cygwin wrote:
> Testcase:
>
> $ uname -r
> 3.5.7-1.x86_64
>
> $ cygcheck -f /bin/cp.exe
> coreutils-9.6-1
>
> $ for i in 1 2 3; do cat /bin/cygwin1.dll > file$i; done
>
> $ compact /C file2 # NTFS compression
> ... (1.7 : 1) ...
>
> $ compact /C /EXE:LZX file3 # Compact OS LZX compression
> ... (2.8 : 1) ...
>
> $ stat -c '%b %s %n' file?
> 2928 2995253 file1
> 1720 2995253 file2
> 1044 2995253 file3
>
> $ cp file1 copy1 # OK
>
> $ cp file2 copy2 # Hangs
> ...[^C]
>
> $ cp file3 copy3 # Hangs
> ...[^C]
>
> $ md5sum file? copy?
> 2954646a9a0fe4579c3fc1f44dd4bb6a *file1
> 2954646a9a0fe4579c3fc1f44dd4bb6a *file2
> 2954646a9a0fe4579c3fc1f44dd4bb6a *file3
> 2954646a9a0fe4579c3fc1f44dd4bb6a *copy1
> 2954646a9a0fe4579c3fc1f44dd4bb6a *copy2
> 2954646a9a0fe4579c3fc1f44dd4bb6a *copy3
>
> $ (sleep 2; pskill strace) & strace cp file3 copy3
> ...
>    47 2004141 [main] cp 5546 lseek: 2995253 = lseek(3, 2995253, 0) # 
> SEEK_SET
>    46 2004187 [main] cp 5546 fhandler_base::lseek: setting file 
> pointer to 2995253 # EOF
>    47 2004234 [main] cp 5546 lseek: 2995253 = lseek(3, 2995253, 3) # 
> SEEK_DATA
>    46 2004280 [main] cp 5546 fhandler_base::lseek: setting file 
> pointer to 2995253
>    47 2004327 [main] cp 5546 lseek: 2995253 = lseek(3, 2995253, 4) # 
> SEEK_HOLE
>    46 2004373 [main] cp 5546 fhandler_base::lseek: setting file 
> pointer to 2995253
>    46 2004419 [main] cp 5546 lseek: 2995253 = lseek(3, 2995253, 0)
>    51 2004470 [main] cp 5546 fhandler_base::lseek: setting file 
> pointer to 2995253
>    47 2004517 [main] cp 5546 lseek: 2995253 = lseek(3, 2995253, 3)
>    47 2004564 [main] cp 5546 fhandler_base::lseek: setting file 
> pointer to 2995253
>    47 2004611 [main] cp 5546 lseek: 2995253 = lseek(3, 2995253, 4)
>    46 2004657 [main] cp 5546 fhandler_base::lseek: setting file 
> pointer to 2995253
> Process strace killed.
>
>
> file1/2 are detected as a possible sparse files but the optimized copy 
> algorithm does not properly handle the non-sparse case. 

Should be "file2/3" of course.

> Upstream bug?
>

Possibly not. A closer look shows that the main loop in 
copy.c:lseek_copy() expects that SEEK_DATA fails with ENXIO at EOF.

https://github.com/coreutils/coreutils/blob/v9.6/src/copy.c#L543

  lseek_copy(..., off_t ext_start, ...)
  {
    ...
    while (0 <= ext_start) {
      {
       ...
       ext_start = lseek (src_fd, dest_pos, SEEK_DATA);
       if (ext_start < 0 && errno != ENXIO)
         goto cannot_lseek;
      }
    ...
}

This works on Linux (checked on Debian 12) but Cygwin returns the offset 
if it is equal to the file size.

Recent POSIX says:
"[ENXIO] The whence argument is SEEK_HOLE or SEEK_DATA, and offset is 
greater than or equal to the file size"
https://pubs.opengroup.org/onlinepubs/9799919799/functions/lseek.html

But (at least older) Linux man pages suggest that Cygwin behavior may be 
correct also:
"In the simplest implementation, a filesystem can support the operations 
by making ... SEEK_DATA always return offset."
"ENXIO - whence is SEEK_DATA or SEEK_HOLE, and offset is beyond the end 
of the file"
https://man7.org/linux/man-pages/man2/lseek.2.html

Hmm... does "beyond" mean '>=' or '>' ?

-- 
Regards,
Christian


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

- Raw text -