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

Previous Next

Full log

View this message in rfc822 format

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

[Message part 1 (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 2 (text/html, inline)]

Previous Next

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