bug#34199: closed (Re: bug#34199: Small bug in cp (for win64))

[Chris Kalish]

Hi, guys ... any word on this? (see below)

-chris


On Sun, Jan 27, 2019 at 9:38 PM Chris Kalish <address@hidden> 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 <address@hidden>.
>
>
> -chris
>
> On Fri, Jan 25, 2019 at 3:35 PM GNU bug Tracking System <
> address@hidden> 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 address@hidden
>>
>> --
>> 34199: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34199
>> GNU Bug Tracking System
>> Contact address@hidden with problems
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Eric Blake <address@hidden>
>> To: Chris Kalish <address@hidden>, address@hidden
>> 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 <address@hidden>
>> To: CP Bugs <address@hidden>
>> 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
>>
>>