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