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

[Chris Kalish]

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
>
>