GNU bug report logs - #34199
Small bug in cp (for win64)

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eric Blake <eblake <at> redhat.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#34199: closed (Small bug in cp (for win64))
Date: Fri, 25 Jan 2019 20:35:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 25 Jan 2019 14:33:57 -0600
with message-id <7d7660bd-9a7d-c762-0ba5-8efaa2f35075 <at> redhat.com>
and subject line Re: bug#34199: Small bug in cp (for win64)
has caused the debbugs.gnu.org bug report #34199,
regarding Small bug in cp (for win64)
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
34199: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34199
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Chris Kalish <chris <at> thekalishes.com>
To: CP Bugs <bug-coreutils <at> gnu.org>
Subject: Small bug in cp (for win64)
Date: Fri, 25 Jan 2019 12:14:42 -0500

[Message part 3 (text/plain, inline)]

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

[Message part 4 (text/html, inline)]

[Message part 5 (message/rfc822, inline)]

From: Eric Blake <eblake <at> redhat.com>
To: Chris Kalish <chris <at> thekalishes.com>, 34199-done <at> debbugs.gnu.org
Subject: Re: bug#34199: Small bug in cp (for win64)
Date: Fri, 25 Jan 2019 14:33:57 -0600

[Message part 6 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.