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-debb...@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 34...@debbugs.gnu.org. > > -- > 34199: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34199 > GNU Bug Tracking System > Contact help-debb...@gnu.org with problems > > > > ---------- Forwarded message ---------- > From: Eric Blake <ebl...@redhat.com> > To: Chris Kalish <ch...@thekalishes.com>, 34199-d...@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 <ch...@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 > >
