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

[Eric Blake]

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
Description: OpenPGP digital signature