From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 25 12:47:05 2019 Received: (at submit) by debbugs.gnu.org; 25 Jan 2019 17:47:05 +0000 Received: from localhost ([127.0.0.1]:45534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gn5ZI-0001kX-P6 for submit@debbugs.gnu.org; Fri, 25 Jan 2019 12:47:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gn54J-0000tT-TW for submit@debbugs.gnu.org; Fri, 25 Jan 2019 12:15:04 -0500 Received: from lists.gnu.org ([209.51.188.17]:47766) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gn54E-0005FF-A1 for submit@debbugs.gnu.org; Fri, 25 Jan 2019 12:14:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gn54D-0008E4-ER for bug-coreutils@gnu.org; Fri, 25 Jan 2019 12:14:58 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gn54C-0005Dk-Nk for bug-coreutils@gnu.org; Fri, 25 Jan 2019 12:14:57 -0500 Received: from mail-lf1-f49.google.com ([209.85.167.49]:38002) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gn54C-0005Cw-Gd for bug-coreutils@gnu.org; Fri, 25 Jan 2019 12:14:56 -0500 Received: by mail-lf1-f49.google.com with SMTP id a8so7455956lfk.5 for ; Fri, 25 Jan 2019 09:14:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=77dOs8Zztx/XU+jadM7HEWtVzEumlEUUoV1wsOujEH4=; b=T695SCGnJUmWwkuU/+6BmA17fSuJA3ps4IKns9iY7mGcoxh+pyf0Qfk9/Wo+tnMWOx v/4t9s3yigV1hZatU60Zft3IP6MRNdHMdmAAsPF5L72TsyoPQykZKSzKFBijp60c603W +aFANgT9aDmwFAFYiH/idl78I8f/8y55aoBEGLFmijXIckRwb9ZQwN4w1QemD5X4YMRX 27KZwar6cUfB4EVpUi5oV4xFKGFEx3dXGKIbHR7Bto7Gf9JBNXnXs1sEAWqGsLVOiqsq PqAd3DK6bJHPFkLSg+N4Vv7Cg4bMJ+WV6ZDlLL+Tlvpr02DGPmIldGDgSsLEIZ/Bjzag COgA== X-Gm-Message-State: AJcUukcWa4zOrEGB3JtK+OvNhrmDxQ86z18Apf801rmbIFRxhwqF4ku8 pxBfImbaOY64HLZ/sjqbxj2Wl5iJPR/rzG9rcEBsCtli X-Google-Smtp-Source: ALg8bN4Yz1aNUso+gUaiUHnUjBngvrwj/hirH8jkchls9lyoBkJgG28L45ebsTbvtZrlJGT9its8yU22caGXpKkud4c= X-Received: by 2002:a19:db54:: with SMTP id s81mr9713699lfg.102.1548436493631; Fri, 25 Jan 2019 09:14:53 -0800 (PST) MIME-Version: 1.0 From: Chris Kalish Date: Fri, 25 Jan 2019 12:14:42 -0500 Message-ID: Subject: Small bug in cp (for win64) To: CP Bugs Content-Type: multipart/alternative; boundary="000000000000290edf05804b7771" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.167.49 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 25 Jan 2019 12:47:01 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000290edf05804b7771 Content-Type: text/plain; charset="UTF-8" Hi, guys ... I use cp to backup source systems to an external drive. It works great (and the --update=number function is a key differentiator). However, I noticed that (for NTFS file systems) long directory names (\abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring) are not supported (they throw "no such file or directory errors"). I assume you're making an assumption on a max static var size (i.e., szDirectory[100]) ... can you either up that allocation or malloc() the memory to the input string? I believe the NTFS fully-cascading filename limit is 32,000 characters. (actual example): *cp: cannot create regular file `C:\\XDrive\\temp\\delete\\KalishCMirror\\XDrive\\Temp\\delete\\GDGBackups\\Presariokids\\LastBackup\\EBackups\\Devin\\DAS\\Documents\\eclipseWS\\2cov2cor\\.settings\\org.eclipse.cdt.managedbuilder.core.prefs': No such file or directory* It will copy if I subst the directory name into a virtual drive letter, but that is not a reasonable solution to recusing my entire drive. Thanks! -chris --000000000000290edf05804b7771 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, guys ... I use cp to backup source sy= stems to an external drive.=C2=A0 It works great (and the --update=3Dnumber= function is a key differentiator).=C2=A0 However, I noticed that (for NTFS= file=C2=A0 systems) long directory names (\abc\def\ghi\jkl\mno\pqrstuvwxyz= \blahblah\longlonglongdirectorystring) are not supported (they throw "= no such file or directory errors").=C2=A0 I assume you're making a= n assumption on a max static var size (i.e., szDirectory[100]) ... can you = either up that allocation or malloc() the memory to the input string?=C2=A0= I believe the NTFS fully-cascading filename limit is 32,000 characters.
(actual example):
cp: cannot crea= te regular file `C:\\XDrive\\temp\\delete\\KalishCMirror\\XDrive\\Temp\\del= ete\\GDGBackups\\Presariokids\\LastBackup\\EBackups\\Devin\\DAS\\Documents\= \eclipseWS\\2cov2cor\\.settings\\org.eclipse.cdt.managedbuilder.core.prefs&= #39;: No such file or directory

It will copy if I subst the directory name into a vir= tual drive letter, but that is not a reasonable solution to recusing my ent= ire drive.

Thanks!

-chris=

--000000000000290edf05804b7771-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 25 15:34:09 2019 Received: (at control) by debbugs.gnu.org; 25 Jan 2019 20:34:09 +0000 Received: from localhost ([127.0.0.1]:45585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gn8Az-0005fp-4e for submit@debbugs.gnu.org; Fri, 25 Jan 2019 15:34:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gn8Av-0005fE-Kd; Fri, 25 Jan 2019 15:34:06 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EA3931B8A; Fri, 25 Jan 2019 20:33:58 +0000 (UTC) Received: from [10.3.117.44] (ovpn-117-44.phx2.redhat.com [10.3.117.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8209C61520; Fri, 25 Jan 2019 20:33:58 +0000 (UTC) Subject: Re: bug#34199: Small bug in cp (for win64) To: Chris Kalish , 34199-done@debbugs.gnu.org References: From: Eric Blake Openpgp: preference=signencrypt Autocrypt: addr=eblake@redhat.com; keydata= xsBNBEvHyWwBCACw7DwsQIh0kAbUXyqhfiKAKOTVu6OiMGffw2w90Ggrp4bdVKmCaEXlrVLU xphBM8mb+wsFkU+pq9YR621WXo9REYVIl0FxKeQo9dyQBZ/XvmUMka4NOmHtFg74nvkpJFCD TUNzmqfcjdKhfFV0d7P/ixKQeZr2WP1xMcjmAQY5YvQ2lUoHP43m8TtpB1LkjyYBCodd+LkV GmCx2Bop1LSblbvbrOm2bKpZdBPjncRNob73eTpIXEutvEaHH72LzpzksfcKM+M18cyRH+nP sAd98xIbVjm3Jm4k4d5oQyE2HwOur+trk2EcxTgdp17QapuWPwMfhaNq3runaX7x34zhABEB AAHNHkVyaWMgQmxha2UgPGVibGFrZUByZWRoYXQuY29tPsLAegQTAQgAJAIbAwULCQgHAwUV CgkICwUWAgMBAAIeAQIXgAUCS8fL9QIZAQAKCRCnoWtKJSdDahBHCACbl/5FGkUqJ89GAjeX RjpAeJtdKhujir0iS4CMSIng7fCiGZ0fNJCpL5RpViSo03Q7l37ss+No+dJI8KtAp6ID+PMz wTJe5Egtv/KGUKSDvOLYJ9WIIbftEObekP+GBpWP2+KbpADsc7EsNd70sYxExD3liwVJYqLc Rw7so1PEIFp+Ni9A1DrBR5NaJBnno2PHzHPTS9nmZVYm/4I32qkLXOcdX0XElO8VPDoVobG6 gELf4v/vIImdmxLh/w5WctUpBhWWIfQDvSOW2VZDOihm7pzhQodr3QP/GDLfpK6wI7exeu3P pfPtqwa06s1pae3ad13mZGzkBdNKs1HEm8x6zsBNBEvHyWwBCADGkMFzFjmmyqAEn5D+Mt4P zPdO8NatsDw8Qit3Rmzu+kUygxyYbz52ZO40WUu7EgQ5kDTOeRPnTOd7awWDQcl1gGBXgrkR pAlQ0l0ReO57Q0eglFydLMi5bkwYhfY+TwDPMh3aOP5qBXkm4qIYSsxb8A+i00P72AqFb9Q7 3weG/flxSPApLYQE5qWGSXjOkXJv42NGS6o6gd4RmD6Ap5e8ACo1lSMPfTpGzXlt4aRkBfvb NCfNsQikLZzFYDLbQgKBA33BDeV6vNJ9Cj0SgEGOkYyed4I6AbU0kIy1hHAm1r6+sAnEdIKj cHi3xWH/UPrZW5flM8Kqo14OTDkI9EtlABEBAAHCwF8EGAEIAAkFAkvHyWwCGwwACgkQp6Fr SiUnQ2q03wgAmRFGDeXzc58NX0NrDijUu0zx3Lns/qZ9VrkSWbNZBFjpWKaeL1fdVeE4TDGm I5mRRIsStjQzc2R9b+2VBUhlAqY1nAiBDv0Qnt+9cLiuEICeUwlyl42YdwpmY0ELcy5+u6wz mK/jxrYOpzXKDwLq5k4X+hmGuSNWWAN3gHiJqmJZPkhFPUIozZUCeEc76pS/IUN72NfprZmF Dp6/QDjDFtfS39bHSWXKVZUbqaMPqlj/z6Ugk027/3GUjHHr8WkeL1ezWepYDY7WSoXwfoAL 2UXYsMAr/uUncSKlfjvArhsej0S4zbqim2ZY6S8aRWw94J3bSvJR+Nwbs34GPTD4Pg== Organization: Red Hat, Inc. Message-ID: <7d7660bd-9a7d-c762-0ba5-8efaa2f35075@redhat.com> Date: Fri, 25 Jan 2019 14:33:57 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jU752NWqx6gKWX8PKLX8BTtFQVNlXkHEc" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 25 Jan 2019 20:33:59 +0000 (UTC) X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jU752NWqx6gKWX8PKLX8BTtFQVNlXkHEc Content-Type: multipart/mixed; boundary="uU3Nb4a6x6TYUwfiRN0SLlhoBr2V3Qllu"; protected-headers="v1" From: Eric Blake To: Chris Kalish , 34199-done@debbugs.gnu.org Message-ID: <7d7660bd-9a7d-c762-0ba5-8efaa2f35075@redhat.com> Subject: Re: bug#34199: Small bug in cp (for win64) References: In-Reply-To: --uU3Nb4a6x6TYUwfiRN0SLlhoBr2V3Qllu Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable tag 34199 notabug thanks On 1/25/19 11:14 AM, Chris Kalish wrote: > Hi, guys ... I use cp to backup source systems to an external drive. I= t > works great (and the --update=3Dnumber function is a key differentiator= ). > However, I noticed that (for NTFS file systems) long directory names > (\abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring)= are > not supported (they throw "no such file or directory errors"). I assum= e > you're making an assumption on a max static var size (i.e., > szDirectory[100]) ... can you either up that allocation or malloc() the= > memory to the input string? I believe the NTFS fully-cascading filenam= e > limit is 32,000 characters. You are incorrect about upstream cp itself having a fixed-size buffer; however, the underlying operating system and/or file system may have limits that you are tripping over. I know that on Windows, whether an application was compiled against ASCII vs. Unicode functions from libc can make a difference on the maximum file name that program can use. However, I can also state that at least the cygwin build of cp (from cygwin.com) does not suffer from the limitation on Windows, and it uses the same upstream cp sources. So I assume that you are using a pre-built cp from some other site than cygwin, and that the limitation is inherent to the porting job of whatever you are using. Therefore, you are better off reporting this to the downstream distributor of the pre-built binary you are using, as upstream is not the problem. I'm marking this as not a bug to avoid it staying open forever in our bug database, but feel free to reply to this with further details, and we can reopen it if you provide more details that points back at the upstream code doing something that interferes with proper long file name usage. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org --uU3Nb4a6x6TYUwfiRN0SLlhoBr2V3Qllu-- --jU752NWqx6gKWX8PKLX8BTtFQVNlXkHEc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAlxLcrUACgkQp6FrSiUn Q2o1DQgAnet1IuvB+um63SwKLh1p0XNHtqRVrX6tikOqr7O7L0zYyK77n0bpMfgi k9EksKXIGYlByJMbjYmVSRGGyDGjvpQYBb+P14N3KJ/dkoPqTtR42x9RJR4bkcUk e7ExK/lMiyR3TMvzlYOuPwvHMCtgv6AhAymHBJ0nfiSx0ZPCOsiQpK8Q35EFPOxC MoWAHxgU+eewq8xqwHr1YddIqKBs/A7nuKEf/oW19qsCLf8Wbc/dc+pEJIicXb/T WgEVNijDsYccrw/m5GA3ltg5PFJj3qXpCJLdq2OkirOOh4bYQ6wvyGN4E54XUGbL 1uGW+lnGChCpi0E6hYTCGffVpHUcYw== =FQMY -----END PGP SIGNATURE----- --jU752NWqx6gKWX8PKLX8BTtFQVNlXkHEc-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 27 22:12:48 2019 Received: (at 34199) by debbugs.gnu.org; 28 Jan 2019 03:12:48 +0000 Received: from localhost ([127.0.0.1]:48128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gnxLr-0003f4-UE for submit@debbugs.gnu.org; Sun, 27 Jan 2019 22:12:48 -0500 Received: from mail-lj1-f175.google.com ([209.85.208.175]:41760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gnwpL-0002tY-0I for 34199@debbugs.gnu.org; Sun, 27 Jan 2019 21:39:12 -0500 Received: by mail-lj1-f175.google.com with SMTP id k15-v6so12854235ljc.8 for <34199@debbugs.gnu.org>; Sun, 27 Jan 2019 18:39:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9XohZnobyYs1ge8VqLF9KOUsb9xxUNW2zOPhtefQBPk=; b=i7wCbH8iYHkkiNpwqg2Y75yFcZxmGBvUfYvumWiouAWzccZN1HkFc+toqebYSnk0wR rrdtDT25ruITz+OSKuFxX5eUnjyOpE2jEcMbm+5Vx6lsW/EwNPIgyfem2gzABB6FhIQ/ Yn3ziSKWJaCirSH85HFLDqEtP/IcUnXnSgkckMLG26t/zHixbQ4x9UaR2T2+ATKDqXPK xD/I66v4zWsh32RIXzcx3Ues3loWtoReb3qjXKw4Rq7A4Mfu1AbJhL4ihhUORvdGMu9k s8EtRXfVl2ueZZ532WwEJe8rywxNTxmuYVtQzKD/bP6UGQ0fffo1WtFbg11HlZnIJAgY RMyA== X-Gm-Message-State: AJcUukcMBI54J4SzkHB2s1j44LGpBxhthLiKDK49QqUlOc2ehhD6tE+g 7jyy+QLqwqjMeGZoBB4WDQZ1lJB2Jk8U8oYDcmlCfHDH X-Google-Smtp-Source: ALg8bN5NxtLLi1UramcLYoJOZ2qy0KGou01WExPJt2Y7JkJc4nDD6IpAhD262Gwm6yp6X/wIt1Q6nmt/AB7ZizDhmIk= X-Received: by 2002:a2e:1b47:: with SMTP id b68-v6mr15597093ljb.104.1548643144507; Sun, 27 Jan 2019 18:39:04 -0800 (PST) MIME-Version: 1.0 References: <7d7660bd-9a7d-c762-0ba5-8efaa2f35075@redhat.com> In-Reply-To: From: Chris Kalish Date: Sun, 27 Jan 2019 21:38:53 -0500 Message-ID: Subject: Re: bug#34199: closed (Re: bug#34199: Small bug in cp (for win64)) To: 34199@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000832bd905807b9445" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34199 X-Mailman-Approved-At: Sun, 27 Jan 2019 22:12:47 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000832bd905807b9445 Content-Type: text/plain; charset="UTF-8" Hmmm ... not sure of the distribution, but the help file pointed me at this address: C:\> cp --version cp (GNU coreutils) 5.3.0 Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\> cp --help .... ..... .... .... As a special case, cp makes a backup of SOURCE when the force and backup options are given and SOURCE and DEST are the same name for an existing, regular file. Report bugs to . -chris On Fri, Jan 25, 2019 at 3:35 PM GNU bug Tracking System < help-debbugs@gnu.org> wrote: > Your bug report > > #34199: Small bug in cp (for win64) > > which was filed against the coreutils package, has been closed. > > The explanation is attached below, along with your original report. > If you require more details, please reply to 34199@debbugs.gnu.org. > > -- > 34199: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34199 > GNU Bug Tracking System > Contact help-debbugs@gnu.org with problems > > > > ---------- Forwarded message ---------- > From: Eric Blake > To: Chris Kalish , 34199-done@debbugs.gnu.org > Cc: > Bcc: > Date: Fri, 25 Jan 2019 14:33:57 -0600 > Subject: Re: bug#34199: Small bug in cp (for win64) > tag 34199 notabug > thanks > > On 1/25/19 11:14 AM, Chris Kalish wrote: > > Hi, guys ... I use cp to backup source systems to an external drive. It > > works great (and the --update=number function is a key differentiator). > > However, I noticed that (for NTFS file systems) long directory names > > (\abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring) > are > > not supported (they throw "no such file or directory errors"). I assume > > you're making an assumption on a max static var size (i.e., > > szDirectory[100]) ... can you either up that allocation or malloc() the > > memory to the input string? I believe the NTFS fully-cascading filename > > limit is 32,000 characters. > > You are incorrect about upstream cp itself having a fixed-size buffer; > however, the underlying operating system and/or file system may have > limits that you are tripping over. I know that on Windows, whether an > application was compiled against ASCII vs. Unicode functions from libc > can make a difference on the maximum file name that program can use. > > However, I can also state that at least the cygwin build of cp (from > cygwin.com) does not suffer from the limitation on Windows, and it uses > the same upstream cp sources. So I assume that you are using a > pre-built cp from some other site than cygwin, and that the limitation > is inherent to the porting job of whatever you are using. Therefore, > you are better off reporting this to the downstream distributor of the > pre-built binary you are using, as upstream is not the problem. I'm > marking this as not a bug to avoid it staying open forever in our bug > database, but feel free to reply to this with further details, and we > can reopen it if you provide more details that points back at the > upstream code doing something that interferes with proper long file name > usage. > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3226 > Virtualization: qemu.org | libvirt.org > > > > > ---------- Forwarded message ---------- > From: Chris Kalish > To: CP Bugs > Cc: > Bcc: > Date: Fri, 25 Jan 2019 12:14:42 -0500 > Subject: Small bug in cp (for win64) > Hi, guys ... I use cp to backup source systems to an external drive. It > works great (and the --update=number function is a key differentiator). > However, I noticed that (for NTFS file systems) long directory names > (\abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring) are > not supported (they throw "no such file or directory errors"). I assume > you're making an assumption on a max static var size (i.e., > szDirectory[100]) ... can you either up that allocation or malloc() the > memory to the input string? I believe the NTFS fully-cascading filename > limit is 32,000 characters. > > (actual example): > > *cp: cannot create regular file > `C:\\XDrive\\temp\\delete\\KalishCMirror\\XDrive\\Temp\\delete\\GDGBackups\\Presariokids\\LastBackup\\EBackups\\Devin\\DAS\\Documents\\eclipseWS\\2cov2cor\\.settings\\org.eclipse.cdt.managedbuilder.core.prefs': > No such file or directory* > > > It will copy if I subst the directory name into a virtual drive letter, > but that is not a reasonable solution to recusing my entire drive. > > Thanks! > > -chris > > --000000000000832bd905807b9445 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmmm ..= . not sure of the distribution, but the help file pointed me at this addres= s:

C:\> cp --version
cp (GNU coreutils) 5.3.0
<= /blockquote>
Written by Torbjorn Granlund, David MacKenzie, and Ji= m Meyering.

<= /blockquote>
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source = for copying conditions.=C2=A0 There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR P= URPOSE.

C:\> cp --help
.... ..... .... ....
As a special case, cp makes a backup = of SOURCE when the force and backup
options are given and SOURCE = and DEST are the same name for an existing,
regular file.

Report bugs to <bug-coreutils@gnu.org>.

-chris

On Fri, Jan 25, 2019 at 3= :35 PM GNU bug Tracking System <= help-debbugs@gnu.org> wrote:
Your bug report

#34199: Small bug in cp (for win64)

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 34199@debbugs.gnu.org.

--
34199: http://debbugs.gnu.org/cgi/bugreport.cgi?= bug=3D34199
GNU Bug Tracking System
Contact help-debb= ugs@gnu.org with problems



---------- Forwarded message ----------
From:=C2=A0Eric Blak= e <eblake@redhat.= com>
To:=C2=A0Chris Kalish <chris@thekalishes.com>, 34199-done@debbugs.gnu.org=
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Fri, 25 Jan 2019 14:33:57 -0600Subject:=C2=A0Re: bug#34199: Small bug in cp (for win64)
tag 34199 not= abug
thanks

On 1/25/19 11:14 AM, Chris Kalish wrote:
> Hi, guys ... I use cp to backup source systems to an external drive.= =C2=A0 It
> works great (and the --update=3Dnumber function is a key differentiato= r).
> However, I noticed that (for NTFS file=C2=A0 systems) long directory n= ames
> (\abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring= ) are
> not supported (they throw "no such file or directory errors"= ).=C2=A0 I assume
> you're making an assumption on a max static var size (i.e.,
> szDirectory[100]) ... can you either up that allocation or malloc() th= e
> memory to the input string?=C2=A0 I believe the NTFS fully-cascading f= ilename
> limit is 32,000 characters.

You are incorrect about upstream cp itself having a fixed-size buffer;
however, the underlying operating system and/or file system may have
limits that you are tripping over.=C2=A0 I know that on Windows, whether an=
application was compiled against ASCII vs. Unicode functions from libc
can make a difference on the maximum file name that program can use.

However, I can also state that at least the cygwin build of cp (from
cygwin.c= om) does not suffer from the limitation on Windows, and it uses
the same upstream cp sources.=C2=A0 So I assume that you are using a
pre-built cp from some other site than cygwin, and that the limitation
is inherent to the porting job of whatever you are using.=C2=A0 Therefore,<= br> you are better off reporting this to the downstream distributor of the
pre-built binary you are using, as upstream is not the problem.=C2=A0 I'= ;m
marking this as not a bug to avoid it staying open forever in our bug
database, but feel free to reply to this with further details, and we
can reopen it if you provide more details that points back at the
upstream code doing something that interferes with proper long file name usage.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+1-919-301-3226
Virtualization:=C2=A0 qemu.org | libvirt.org




---------- Forwarded message ----------
From:=C2=A0Chris Kal= ish <chris@th= ekalishes.com>
To:=C2=A0CP Bugs <bug-coreutils@gnu.org>
Cc:=C2=A0Bcc:=C2=A0
Date:=C2=A0Fri, 25 Jan 2019 12:14:42 -0500
Subject:=C2=A0= Small bug in cp (for win64)
Hi, guys .= .. I use cp to backup source systems to an external drive.=C2=A0 It works g= reat (and the --update=3Dnumber function is a key differentiator).=C2=A0 Ho= wever, I noticed that (for NTFS file=C2=A0 systems) long directory names (\= abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring) are n= ot supported (they throw "no such file or directory errors").=C2= =A0 I assume you're making an assumption on a max static var size (i.e.= , szDirectory[100]) ... can you either up that allocation or malloc() the m= emory to the input string?=C2=A0 I believe the NTFS fully-cascading filenam= e limit is 32,000 characters.

(actual example):
cp: cannot create regular file `C:\\XDrive\\temp\\de= lete\\KalishCMirror\\XDrive\\Temp\\delete\\GDGBackups\\Presariokids\\LastBa= ckup\\EBackups\\Devin\\DAS\\Documents\\eclipseWS\\2cov2cor\\.settings\\org.= eclipse.cdt.managedbuilder.core.prefs': No such file or directory

It will copy if= I subst the directory name into a virtual drive letter, but that is not a = reasonable solution to recusing my entire drive.

T= hanks!

-chris

--000000000000832bd905807b9445-- From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 09 15:13:09 2019 Received: (at 34199) by debbugs.gnu.org; 9 Feb 2019 20:13:10 +0000 Received: from localhost ([127.0.0.1]:41557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gsYzs-0004vz-VF for submit@debbugs.gnu.org; Sat, 09 Feb 2019 15:13:09 -0500 Received: from mail-lf1-f42.google.com ([209.85.167.42]:46948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gsY23-0001Oh-N8 for 34199@debbugs.gnu.org; Sat, 09 Feb 2019 14:11:20 -0500 Received: by mail-lf1-f42.google.com with SMTP id f5so4887038lfc.13 for <34199@debbugs.gnu.org>; Sat, 09 Feb 2019 11:11:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dhzgHR6xLN07jPPIbbFISFj/E+vXOLlS3yXb7c/ZwLI=; b=OUxPzO43aEWKxqXQXSVIJTLT+0ZDOFmIq6gsBNsNk7Mb5f6KRjtJ0B5UoXInV/rFRA nx8/9EK+z58RT8ZJ474ckVB5cRYUgDHELxZ1L6Zbv+FoX1pnWgXX1anyc/tR7obkDfpI yp7AQViBFgc8FpqcbDD2DwS/LRaOcNcU7CHbsA7zt4gMpPwWy9m65OQLc7hZt013O+s2 wRkscfvfmlW2VX30vtfx+GeFRzjbg4g2WVJBmO5yVwlaFHhbKkZu0ZbXhh/mXEGoGulB 6akbUf4pTlzgmPvdL/UmwFo8tBBZ8oRyYCxyoNowDgSkFFoTqL6qYcxRW1XfFBMyxwNe 8rug== X-Gm-Message-State: AHQUAubjOkd5jlGd/3cUCfi1TFJ7NUSW3yhBbwli4L0PKoEDN9vNqghR eq1H8hEdpGhQLouJ2dtqFmAOO+4ZXnOvDaAeq3qd7g== X-Google-Smtp-Source: AHgI3IbLJmRB6ENFyW6Fha18Gtik0qj92W51f1e/yFOg7IHvro9SVasF7W9LwxFKolo0NEKM/+k7CppEdDzAjDnnZw8= X-Received: by 2002:a19:a7c5:: with SMTP id q188mr18188474lfe.102.1549739473284; Sat, 09 Feb 2019 11:11:13 -0800 (PST) MIME-Version: 1.0 References: <7d7660bd-9a7d-c762-0ba5-8efaa2f35075@redhat.com> In-Reply-To: From: Chris Kalish Date: Sat, 9 Feb 2019 14:10:59 -0500 Message-ID: Subject: Re: bug#34199: closed (Re: bug#34199: Small bug in cp (for win64)) To: 34199@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000ccb41605817ad631" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34199 X-Mailman-Approved-At: Sat, 09 Feb 2019 15:13:08 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000ccb41605817ad631 Content-Type: text/plain; charset="UTF-8" Hi, guys ... any word on this? (see below) -chris On Sun, Jan 27, 2019 at 9:38 PM Chris Kalish wrote: > Hmmm ... not sure of the distribution, but the help file pointed me at > this address: > > C:\> cp --version > > cp (GNU coreutils) 5.3.0 > > Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering. > > > Copyright (C) 2005 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > C:\> cp --help > .... ..... .... .... > As a special case, cp makes a backup of SOURCE when the force and backup > options are given and SOURCE and DEST are the same name for an existing, > regular file. > > Report bugs to . > > > -chris > > On Fri, Jan 25, 2019 at 3:35 PM GNU bug Tracking System < > help-debbugs@gnu.org> wrote: > >> Your bug report >> >> #34199: Small bug in cp (for win64) >> >> which was filed against the coreutils package, has been closed. >> >> The explanation is attached below, along with your original report. >> If you require more details, please reply to 34199@debbugs.gnu.org. >> >> -- >> 34199: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34199 >> GNU Bug Tracking System >> Contact help-debbugs@gnu.org with problems >> >> >> >> ---------- Forwarded message ---------- >> From: Eric Blake >> To: Chris Kalish , 34199-done@debbugs.gnu.org >> Cc: >> Bcc: >> Date: Fri, 25 Jan 2019 14:33:57 -0600 >> Subject: Re: bug#34199: Small bug in cp (for win64) >> tag 34199 notabug >> thanks >> >> On 1/25/19 11:14 AM, Chris Kalish wrote: >> > Hi, guys ... I use cp to backup source systems to an external drive. It >> > works great (and the --update=number function is a key differentiator). >> > However, I noticed that (for NTFS file systems) long directory names >> > (\abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring) >> are >> > not supported (they throw "no such file or directory errors"). I assume >> > you're making an assumption on a max static var size (i.e., >> > szDirectory[100]) ... can you either up that allocation or malloc() the >> > memory to the input string? I believe the NTFS fully-cascading filename >> > limit is 32,000 characters. >> >> You are incorrect about upstream cp itself having a fixed-size buffer; >> however, the underlying operating system and/or file system may have >> limits that you are tripping over. I know that on Windows, whether an >> application was compiled against ASCII vs. Unicode functions from libc >> can make a difference on the maximum file name that program can use. >> >> However, I can also state that at least the cygwin build of cp (from >> cygwin.com) does not suffer from the limitation on Windows, and it uses >> the same upstream cp sources. So I assume that you are using a >> pre-built cp from some other site than cygwin, and that the limitation >> is inherent to the porting job of whatever you are using. Therefore, >> you are better off reporting this to the downstream distributor of the >> pre-built binary you are using, as upstream is not the problem. I'm >> marking this as not a bug to avoid it staying open forever in our bug >> database, but feel free to reply to this with further details, and we >> can reopen it if you provide more details that points back at the >> upstream code doing something that interferes with proper long file name >> usage. >> >> -- >> Eric Blake, Principal Software Engineer >> Red Hat, Inc. +1-919-301-3226 >> Virtualization: qemu.org | libvirt.org >> >> >> >> >> ---------- Forwarded message ---------- >> From: Chris Kalish >> To: CP Bugs >> Cc: >> Bcc: >> Date: Fri, 25 Jan 2019 12:14:42 -0500 >> Subject: Small bug in cp (for win64) >> Hi, guys ... I use cp to backup source systems to an external drive. It >> works great (and the --update=number function is a key differentiator). >> However, I noticed that (for NTFS file systems) long directory names >> (\abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring) are >> not supported (they throw "no such file or directory errors"). I assume >> you're making an assumption on a max static var size (i.e., >> szDirectory[100]) ... can you either up that allocation or malloc() the >> memory to the input string? I believe the NTFS fully-cascading filename >> limit is 32,000 characters. >> >> (actual example): >> >> *cp: cannot create regular file >> `C:\\XDrive\\temp\\delete\\KalishCMirror\\XDrive\\Temp\\delete\\GDGBackups\\Presariokids\\LastBackup\\EBackups\\Devin\\DAS\\Documents\\eclipseWS\\2cov2cor\\.settings\\org.eclipse.cdt.managedbuilder.core.prefs': >> No such file or directory* >> >> >> It will copy if I subst the directory name into a virtual drive letter, >> but that is not a reasonable solution to recusing my entire drive. >> >> Thanks! >> >> -chris >> >> --000000000000ccb41605817ad631 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, guys ... any word on this? (see below= )

-chris


On Sun, Jan 27, 2019 at 9:3= 8 PM Chris Kalish <chris@thekal= ishes.com> wrote:
Hmmm ... not sure of the distribution, but the help file pointed me at = this address:

C:\> cp --versi= on
cp (GNU coreutils) 5.3.0
Written by Torbjorn Granlund, David MacKen= zie, and Jim Meyering.

Copyright (C) 2005 Free Software Foundatio= n, Inc.
This is free software; see = the source for copying conditions.=C2=A0 There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A P= ARTICULAR PURPOSE.

C:\> cp --he= lp
.... ..... .... ....
As a special case, cp make= s a backup of SOURCE when the force and backup
options are given = and SOURCE and DEST are the same name for an existing,
regular fi= le.

Report bugs to <bug-coreutils@gnu.org>.
<= /div>

-chris

On Fri, Jan 25, 2019 at 3:35 PM GNU bug Tracking System <help-debbugs@gnu.org>= wrote:
Your bug= report

#34199: Small bug in cp (for win64)

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 34199@debbugs.gnu.org.

--
34199: http://debbugs.gnu.org/cgi/bugreport.cgi?= bug=3D34199
GNU Bug Tracking System
Contact help-debb= ugs@gnu.org with problems



---------- Forwarded message ----------
From:=C2=A0Eric Blak= e <eblake@redhat.= com>
To:=C2=A0Chris Kalish <chris@thekalishes.com>, 34199-done@debbugs.gnu.org=
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Fri, 25 Jan 2019 14:33:57 -0600Subject:=C2=A0Re: bug#34199: Small bug in cp (for win64)
tag 34199 not= abug
thanks

On 1/25/19 11:14 AM, Chris Kalish wrote:
> Hi, guys ... I use cp to backup source systems to an external drive.= =C2=A0 It
> works great (and the --update=3Dnumber function is a key differentiato= r).
> However, I noticed that (for NTFS file=C2=A0 systems) long directory n= ames
> (\abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring= ) are
> not supported (they throw "no such file or directory errors"= ).=C2=A0 I assume
> you're making an assumption on a max static var size (i.e.,
> szDirectory[100]) ... can you either up that allocation or malloc() th= e
> memory to the input string?=C2=A0 I believe the NTFS fully-cascading f= ilename
> limit is 32,000 characters.

You are incorrect about upstream cp itself having a fixed-size buffer;
however, the underlying operating system and/or file system may have
limits that you are tripping over.=C2=A0 I know that on Windows, whether an=
application was compiled against ASCII vs. Unicode functions from libc
can make a difference on the maximum file name that program can use.

However, I can also state that at least the cygwin build of cp (from
cygwin.c= om) does not suffer from the limitation on Windows, and it uses
the same upstream cp sources.=C2=A0 So I assume that you are using a
pre-built cp from some other site than cygwin, and that the limitation
is inherent to the porting job of whatever you are using.=C2=A0 Therefore,<= br> you are better off reporting this to the downstream distributor of the
pre-built binary you are using, as upstream is not the problem.=C2=A0 I'= ;m
marking this as not a bug to avoid it staying open forever in our bug
database, but feel free to reply to this with further details, and we
can reopen it if you provide more details that points back at the
upstream code doing something that interferes with proper long file name usage.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+1-919-301-3226
Virtualization:=C2=A0 qemu.org | libvirt.org




---------- Forwarded message ----------
From:=C2=A0Chris Kal= ish <chris@th= ekalishes.com>
To:=C2=A0CP Bugs <bug-coreutils@gnu.org>
Cc:=C2=A0Bcc:=C2=A0
Date:=C2=A0Fri, 25 Jan 2019 12:14:42 -0500
Subject:=C2=A0= Small bug in cp (for win64)
Hi, guys .= .. I use cp to backup source systems to an external drive.=C2=A0 It works g= reat (and the --update=3Dnumber function is a key differentiator).=C2=A0 Ho= wever, I noticed that (for NTFS file=C2=A0 systems) long directory names (\= abc\def\ghi\jkl\mno\pqrstuvwxyz\blahblah\longlonglongdirectorystring) are n= ot supported (they throw "no such file or directory errors").=C2= =A0 I assume you're making an assumption on a max static var size (i.e.= , szDirectory[100]) ... can you either up that allocation or malloc() the m= emory to the input string?=C2=A0 I believe the NTFS fully-cascading filenam= e limit is 32,000 characters.

(actual example):
cp: cannot create regular file `C:\\XDrive\\temp\\de= lete\\KalishCMirror\\XDrive\\Temp\\delete\\GDGBackups\\Presariokids\\LastBa= ckup\\EBackups\\Devin\\DAS\\Documents\\eclipseWS\\2cov2cor\\.settings\\org.= eclipse.cdt.managedbuilder.core.prefs': No such file or directory

It will copy if= I subst the directory name into a virtual drive letter, but that is not a = reasonable solution to recusing my entire drive.

T= hanks!

-chris

--000000000000ccb41605817ad631-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 10 17:17:47 2019 Received: (at 34199) by debbugs.gnu.org; 10 Feb 2019 22:17:47 +0000 Received: from localhost ([127.0.0.1]:42911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gsxQ3-0000zz-6N for submit@debbugs.gnu.org; Sun, 10 Feb 2019 17:17:47 -0500 Received: from havoc.proulx.com ([96.88.95.61]:52753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gsxQ1-0000zm-Ex for 34199@debbugs.gnu.org; Sun, 10 Feb 2019 17:17:46 -0500 Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id B4D4B27CB; Sun, 10 Feb 2019 15:17:39 -0700 (MST) Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 8486121174; Sun, 10 Feb 2019 15:17:39 -0700 (MST) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 6FCE62DC80; Sun, 10 Feb 2019 15:17:39 -0700 (MST) Date: Sun, 10 Feb 2019 15:17:39 -0700 From: Bob Proulx To: Chris Kalish Subject: Re: bug#34199: closed (Re: bug#34199: Small bug in cp (for win64)) Message-ID: <20190210145537081453897@bob.proulx.com> References: <7d7660bd-9a7d-c762-0ba5-8efaa2f35075@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34199 Cc: 34199@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Chris Kalish wrote: > Hmmm ... not sure of the distribution, but the help file pointed me at this > address: > C:\> cp --version > cp (GNU coreutils) 5.3.0 I always hate it when I am on your side of things and upstream says this to me. But here I am on the other side and going to say almost exactly the thing I hate to hear. Coreutils 5.3.0 was released on 2005-01-08 and today is 2019-02-10 making that version of the program you are running 14 years old! That is a very long time ago. Since you are running on MS-Windows I will say that was probably five whole versions of Microsoft ago! It would not be practically possible for most of us to recreate that version on MS-Windows-XP of that era. This makes it difficult to impossible to do anything about even if we had an alive build system from 2005 still running. Plus here we are concerned about software on free(dom) licensed platforms and Microsoft is a closed source proprietary platform. That was always supported by other teams doing ports to non-free operating systems. What's a developer to do? :-( Perhaps I should ignore all of the years and simply say, yes, that is a bug. (I don't really know. But I will say it. Searching the changelogs will show that 5.3.0 did introduce a number of bugs.) And we have fixed it! The new version is v8.30 and that bug is fixed. Eric reported that it was not a problem for Cygwin on MS-Windows. Please upgrade to it and confirm with us that it is working for you there. Maybe that would be a less unpleasant to hear? :-) > C:\> cp --help > Report bugs to . We are happy to have bugs reported here. But often in ports the behavior is dependent upon the port environment. That is outside of our control. Please do upgrade to a newer version. Cygwin tends to be the most capable version. Although there are other ports too. We would appreciate hearing about how this worked out for you regardless. And maybe along the way you might consider upgrading to a free(dom) software licensed operating system? Then you would have upgrades available by default. :-) Bob From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 12 13:19:08 2019 Received: (at 34199) by debbugs.gnu.org; 12 Feb 2019 18:19:08 +0000 Received: from localhost ([127.0.0.1]:45191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gtceB-0004Sh-OO for submit@debbugs.gnu.org; Tue, 12 Feb 2019 13:19:08 -0500 Received: from mail-lj1-f177.google.com ([209.85.208.177]:35402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gtcZs-0004Jv-5V for 34199@debbugs.gnu.org; Tue, 12 Feb 2019 13:14:40 -0500 Received: by mail-lj1-f177.google.com with SMTP id j13-v6so3080562ljc.2 for <34199@debbugs.gnu.org>; Tue, 12 Feb 2019 10:14:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cm2o7HwLHaQtH2nxpRwU3dSQnxSvCueSn8nxyT+k0lw=; b=bfEL7UpcErj687Kh3dmEvmWP+s/2doAzUufVGwkJh+1B0SGb3TJkoNo1MvHEJAMQde wLuIsc7toQo0CBvIvVwYjXIMFN08njgcpoVWbY9QyO4pUenG8WFs0a364uTl4cZHkLyg SbjIZrMvOWgrJyXiyPhcwE/LG1tesOx5qjPCSQMSJinJI6S2fdFeeCVrmkfy1LF/fKF+ Hs/foqRuR4sofolkpZw7emin+YpFylj97STwOa9E0bpMbmeL4V5ef5LwsyKtTr1ZrMLj AkSnf8u2Hi3MULeFu/icKGGqoNCwfBFRDMNDfy64ckCh6EHaA4cyJYOmOYiUICBqvJEB iSCg== X-Gm-Message-State: AHQUAubknL/AXoqfxPRIaOpbaZl7pXhYm5xwavjktG4afavSUERJGayp Jmz6A07MjP6X31Zx7qzU/ixbiAWKdjwHY4Rymccv90Pl X-Google-Smtp-Source: AHgI3IYXNzqu1uPaXqWxgKxC52aW4qfzemyRnqh363+vhFCcFqBEV0izFR9vrBhckT5bggVVfTshtLSFc+Rc5GrQ/pQ= X-Received: by 2002:a2e:7f04:: with SMTP id a4-v6mr3039456ljd.156.1549995273935; Tue, 12 Feb 2019 10:14:33 -0800 (PST) MIME-Version: 1.0 References: <7d7660bd-9a7d-c762-0ba5-8efaa2f35075@redhat.com> <20190210145537081453897@bob.proulx.com> In-Reply-To: <20190210145537081453897@bob.proulx.com> From: Chris Kalish Date: Tue, 12 Feb 2019 13:14:21 -0500 Message-ID: Subject: Re: bug#34199: closed (Re: bug#34199: Small bug in cp (for win64)) To: Bob Proulx Content-Type: multipart/alternative; boundary="000000000000b4e00e0581b665cc" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34199 X-Mailman-Approved-At: Tue, 12 Feb 2019 13:19:04 -0500 Cc: 34199@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000b4e00e0581b665cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Bob ... thanks so much for the info! (very entertaining!) =F0=9F=A4=93 You were right ... I had installed the newer version of Coreutils from cygwin and that works better (but still has some NTFS-related bugs, I think). New version: C:\temp\x\x>cp --version cp (GNU coreutils) 8.26 Packaged by Cygwin (8.26-2) Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering. 1. Does not seem to like directories or filenames with European characters: *Windows Copy (works):* C:\temp\x\x>copy /b "t:\xdrive\SameTimeChatTranscripts\CN=3DLinda Ba=C3=B1uelos,OU=3DCorporate,O=3DGeneralElectric" . t:\xdrive\SameTimeChatTranscripts\CN=3DLinda Ba=C3=B1uelos,OU=3DCorporate,O=3DGeneralElectric\ChatHistory.properties 1 file(s) copied. *CP (does not work):* C:\temp\x\x>cp "t:\xdrive\SameTimeChatTranscripts\CN=3DLinda Ba=C3=B1uelos,OU=3DCorporate,O=3DGeneralElectric" . cp: cannot stat '"t:\xdrive\SameTimeChatTranscripts\CN=3DLinda Ba'$'\303\261''uelos,OU=3DCorporate,O=3DGeneralElectric"': No such file or directory There seems to be a problem with long directory names, still, but I'm still working on isolating that. Can you give any insight into the above? Thanks!!!! -chris On Sun, Feb 10, 2019 at 5:17 PM Bob Proulx wrote: > Chris Kalish wrote: > > Hmmm ... not sure of the distribution, but the help file pointed me at > this > > address: > > > C:\> cp --version > > cp (GNU coreutils) 5.3.0 > > I always hate it when I am on your side of things and upstream says > this to me. But here I am on the other side and going to say almost > exactly the thing I hate to hear. > > Coreutils 5.3.0 was released on 2005-01-08 and today is 2019-02-10 > making that version of the program you are running 14 years old! That > is a very long time ago. Since you are running on MS-Windows I will > say that was probably five whole versions of Microsoft ago! It would > not be practically possible for most of us to recreate that version on > MS-Windows-XP of that era. This makes it difficult to impossible to > do anything about even if we had an alive build system from 2005 still > running. Plus here we are concerned about software on free(dom) > licensed platforms and Microsoft is a closed source proprietary > platform. That was always supported by other teams doing ports to > non-free operating systems. What's a developer to do? :-( > > Perhaps I should ignore all of the years and simply say, yes, that is > a bug. (I don't really know. But I will say it. Searching the > changelogs will show that 5.3.0 did introduce a number of bugs.) And > we have fixed it! The new version is v8.30 and that bug is fixed. > Eric reported that it was not a problem for Cygwin on MS-Windows. > Please upgrade to it and confirm with us that it is working for you > there. Maybe that would be a less unpleasant to hear? :-) > > > C:\> cp --help > > Report bugs to . > > We are happy to have bugs reported here. But often in ports the > behavior is dependent upon the port environment. That is outside of > our control. > > Please do upgrade to a newer version. Cygwin tends to be the most > capable version. Although there are other ports too. We would > appreciate hearing about how this worked out for you regardless. > > And maybe along the way you might consider upgrading to a free(dom) > software licensed operating system? Then you would have upgrades > available by default. :-) > > Bob > --000000000000b4e00e0581b665cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Bob ... thanks = so much for the info! (very entertaining!) =F0=9F=A4=93

You were right ... I had installed the newer version of Coreutils fro= m cygwin and that works better (but still has some NTFS-related bugs, I thi= nk).

New version:
C:\temp\x\x>cp --version
cp (GN= U coreutils) 8.26
Packaged by Cygwin (8.26-2)
=
Copyrig= ht (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU G= PL version 3 or later <http= ://gnu.org/licenses/gpl.html>.
This is free software: you= are free to change and redistribute it.
There is NO WARRANTY, t= o the extent permitted by law.

Written by Torbjo= rn Granlund, David MacKenzie, and Jim Meyering.


<= /div>
1. Does not seem to like directories or filenames with European c= haracters:

Windows Copy (works):
C:\temp\x\x>copy /b "t:\xdrive\Same= TimeChatTranscripts\CN=3DLinda Ba=C3=B1uelos,OU=3DCorporate,O=3DGeneralElec= tric" .
t:\xdrive\SameTimeChatTranscripts\CN=3DLind= a Ba=C3=B1uelos,OU=3DCorporate,O=3DGeneralElectric\ChatHistory.properties
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1 file(s) copied.
CP (does not work):
C:\temp\x\x>cp "t:\= xdrive\SameTimeChatTranscripts\CN=3DLinda Ba=C3=B1uelos,OU=3DCorporate,O=3D= GeneralElectric" .
cp: cannot stat '"t:\xd= rive\SameTimeChatTranscripts\CN=3DLinda Ba'$'\303\261''uelo= s,OU=3DCorporate,O=3DGeneralElectric"': No such file or directory<= /font>

There seems to be a problem with long directory names, still, but I'm = still working on isolating that.=C2=A0 Can you give any insight into the ab= ove?

Thanks!!!!

-chris

On Sun, Feb 10, 2019 at 5:17 PM Bob Proulx &= lt;bob@proulx.com> wrote:
Chris Kalish wrote:
> Hmmm ... not sure of the distribution, but the help file pointed me at= this
> address:

> C:\> cp --version
> cp (GNU coreutils) 5.3.0

I always hate it when I am on your side of things and upstream says
this to me.=C2=A0 But here I am on the other side and going to say almost exactly the thing I hate to hear.

Coreutils 5.3.0 was released on 2005-01-08 and today is 2019-02-10
making that version of the program you are running 14 years old!=C2=A0 That=
is a very long time ago.=C2=A0 Since you are running on MS-Windows I will say that was probably five whole versions of Microsoft ago!=C2=A0 It would<= br> not be practically possible for most of us to recreate that version on
MS-Windows-XP of that era.=C2=A0 This makes it difficult to impossible to do anything about even if we had an alive build system from 2005 still
running.=C2=A0 Plus here we are concerned about software on free(dom)
licensed platforms and Microsoft is a closed source proprietary
platform.=C2=A0 That was always supported by other teams doing ports to
non-free operating systems.=C2=A0 What's a developer to do? :-(

Perhaps I should ignore all of the years and simply say, yes, that is
a bug.=C2=A0 (I don't really know.=C2=A0 But I will say it.=C2=A0 Searc= hing the
changelogs will show that 5.3.0 did introduce a number of bugs.)=C2=A0 And<= br> we have fixed it!=C2=A0 The new version is v8.30 and that bug is fixed.
Eric reported that it was not a problem for Cygwin on MS-Windows.
Please upgrade to it and confirm with us that it is working for you
there.=C2=A0 Maybe that would be a less unpleasant to hear? :-)

> C:\> cp --help
> Report bugs to <bug-coreutils@gnu.org>.

We are happy to have bugs reported here.=C2=A0 But often in ports the
behavior is dependent upon the port environment.=C2=A0 That is outside of our control.

Please do upgrade to a newer version.=C2=A0 Cygwin tends to be the most
capable version.=C2=A0 Although there are other ports too.=C2=A0 We would appreciate hearing about how this worked out for you regardless.

And maybe along the way you might consider upgrading to a free(dom)
software licensed operating system?=C2=A0 Then you would have upgrades
available by default. :-)

Bob
--000000000000b4e00e0581b665cc-- From unknown Mon Jun 23 04:11:23 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 13 Mar 2019 11:24:13 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator