bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13893: bug in CP


From: Eric Blake
Subject: bug#13893: bug in CP
Date: Wed, 06 Mar 2013 14:57:32 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3

On 03/06/2013 01:23 PM, Kevin C. Redden wrote:
> Sir:
> 
> I'm using Debian 6.06/KDE 4.4, and I found either a bug, or else an
> omission in CP.
> 
> I tried to copy files from one directory to another with the command
> 
> address@hidden:/STORE2/TH-zeus/work-desk/WRITNG/WRITING-CURRENT$ cp -R *
> /media/SNEAKERNET1/
> 
> It goes about half-way, then completely aborts with:
> 
> cp: cannot create directory
> `/media/SNEAKERNET1/Tools/NEW-FOLDER-FRAMEWORK ': Invalid argument

Notice the trailing space.  Also, notice that your destination file is
mounted under /media, and these days, most /media mounts are to USB
flash sticks, which in turn tend to be default-formatted as FAT.  The
FAT file system is puny - among other things, it doesn't permit trailing
spaces in file names.  The kernel is telling you that it cannot create
the desired filename with a trailing space because of the restrictions
of the destination file system.

> 
> I honestly don't know what's wrong with that directory, but Dolphin
> cannot copy it as well. I was finally able to copy the files with a SU
> midnight commander. When MC ttried to copy that file it just asked if I
> wish to skip it which I did, and MC finished copying the rest of the files.
> 
> First I'm wondering; is this a bug? If not, is there a way to force CP
> to copy files without aborting if it runs into a problem? There is a
> command in Windows called 'Xcopy'. It has a command switch telling it to
> just skip over bad files, and copy the rest. I cannot recall exactly
> what the command is, since I've been off windows for quite awhile. But
> it's something like 'xcopy -c *.* /dir.' (-c for 'continue')

This is not a bug, but a limitation of your choice of file systems.
Rename the file on the source to something that doesn't violate FAT
naming requirements, and then you will be able to copy things.  Or
reformat your USB stick to use ext4 or other similar more-permissive
filesystem (although based on the name of your media, you are planning
on sneaker-netting your files to another machine, so pick a filesystem
that the destination OS can read).

> 
> If this is a bug, or an omission. Can I request that someone fix cp for
> either a command switch like Xcopy's, or else at least default to just
> skip bad files, instead of aborting completely? This abort problem has
> also plagued both windows and linux file managers for years (except for
> MC) and it's frankly very annoying.

cp should have copied as much as possible, without recursing into the
impossible directory name.  If you can prove that cp aborted early
instead of copying all remaining files, even after failing on that one
directory, then we have a bug to fix.  But if only that one directory
(and all its descendants) were the only things omitted in your recursive
copy, then 'cp' did its job as best it could in spite of the kernel
restriction against creating impossible files on less-capabilt file systems.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]