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 <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=34199
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems



---------- Forwarded message ----------
From: Eric Blake <eblake@redhat.com>
To: Chris Kalish <chris@thekalishes.com>, 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 <chris@thekalishes.com>
To: CP Bugs <bug-coreutils@gnu.org>
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