[karmic] case sensitivity broken for file copy

[Roland Hughes]

Binary package hint: dolphin

In trying to work around the Dolphin directory copy bug reported earlier, I dropped to the command line to perform an old fashioned file copy. I was stunned when I saw the following two errors:

cp: cannot create regular file `/media/usb_d1/ws_roland/fuelsurcharge3/doeHistory.java~': File exists
cp: cannot create regular file `/media/usb_d1/ws_roland/fuelsurcharge3/SurchargeRate.java~': File exists

The source directory had the following:
DoeHistory.java~ doeHistory.java~
surchargeRate.java~ SurchargeRate.java~

It appears something in the CP process is ignoring case. The copy command couldn't have been simpler.

roland@logikaldesktop:~$ cp -r * /media/usb_d1/ws_roland

[Rohan Garg (rohangarg)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner.
There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test the current Ubuntu development version (10.10). If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect 482701, and any other logs that are relevant for this particular issue.

[Andrew McCarthy (andrewmccarthy)]

My guess is that the destination folder, /media/usb_d1/, is an external drive formatted with FAT32 or some other windows-style filesystem that is case-insensitive. Can you confirm if this is the case? Thanks.

[Roland Hughes (original-seasoned-geek)]

That has always been the case, both when it worked prior to Karmic, and
when it failed with Karmic.

Somewhere in this history you should also find that I tried copying to
an extn formatted partition with the same failure.

Today, I applied all updates to my KUbuntu 64-bit AMD 10.10 system and
re-ran the test twice:

NTFS USB drive: Couldn't read some hidden socket files nor the Firebird
data directory. All understandable.

FAT-32: Same issues as above plus it could not write most/all
".evolution" directories...it appears the full blow file name was just
too long, so all email basically lost. No symlinks were copied.
Did not get a single overwrite error message about upper and lower case
file names conflicting, which was the original complaint in this bug.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol
reserves.

On Wed, 2011-03-02 at 21:52 +0000, Andrew McCarthy wrote:

> My guess is that the destination folder, /media/usb_d1/, is an external
> drive formatted with FAT32 or some other windows-style filesystem that
> is case-insensitive. Can you confirm if this is the case? Thanks.
>
> ** Changed in: coreutils (Ubuntu)
> Status: New => Incomplete
>

[Andrew McCarthy (andrewmccarthy)]

Okay. Well, unfortunately I can't reproduce this here, so perhaps somebody else can suggest something. Best of luck!

[C de-Avillez (hggdh2)]

'cp' does not ignore case. It may well happen that the target filesystem is case-insensitive, or case-confused -- and 'cp' will be hit by an error like you reported. This is not a coreutils issue, but a limitation of the target filesystem.

No matter what (and even if 'cp' was indeed at fault) we would need detailed data to follow this up:

* target filesystem type
* exact command issued and responses
* Ubuntu and coreutils versions (as shown via 'dpkg -l coreutils' and 'lsb_release -a').

For the new issues, I suggest opening new bugs, after verifying it is not a target filesystem limitation).

Closing INVALID; please reopen if you do not agree, or have additional information.

[Roland Hughes (original-seasoned-geek)]

I re-opened as I do not agree.

The bug was completely reproducible at the time. You were given the _exact_ command issued in the original post. If you needed more information then you shouldn't have waited to ask for it until nearly a year after that bug forced an upgrade.

The usb_d1 device definitely is an external usb drive FAT-32 formatted. It has since been replaced by a 1TB drive formatted the same way. You can ignore the firebird data errors below, Firebird has to own the directory it writes to.

roland@roland-Generic-Desktop1:~$ cp -r * /media/usb_1tb/ws_roland
cp: cannot open `fb_data/tax_2002.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2580.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2576' for reading: Permission denied
cp: cannot open `fb_data/tax_2556' for reading: Permission denied
cp: cannot open `fb_data/tax_2558' for reading: Permission denied
cp: cannot open `fb_data/tax_2570' for reading: Permission denied
cp: cannot open `fb_data/tax_2006.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2592.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2573' for reading: Permission denied
cp: cannot open `fb_data/tax_2562' for reading: Permission denied
cp: cannot open `fb_data/tax_2010.fdb' for reading: Permission denied
cp: cannot open `fb_data/test.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2574' for reading: Permission denied
cp: cannot open `fb_data/tax_1993.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2557' for reading: Permission denied
cp: cannot open `fb_data/tax_2004.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_1995.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2563' for reading: Permission denied
cp: cannot open `fb_data/tax_2560' for reading: Permission denied
cp: cannot open `fb_data/tax_2559' for reading: Permission denied
cp: cannot open `fb_data/tax_2003.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2009.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2577' for reading: Permission denied
cp: cannot open `fb_data/tax_1992.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2543' for reading: Permission denied
cp: cannot open `fb_data/2590_tax.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2000.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_1997.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2571' for reading: Permission denied
cp: cannot open `fb_data/tax_1994.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2578.fb' for reading: Permission denied
cp: cannot open `fb_data/tax_2578' for reading: Permission denied
cp: cannot open `fb_data/tax_2007.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_1999.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2575' for reading: Permission denied
cp: cannot open `fb_data/tax_1996.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_2005.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax_1998.fdb' for reading: Permission denied
cp: cannot open `fb_data/tax...

[C de-Avillez (hggdh2)]

As I stated earlier, some filesystems are case-insensitive. FAT is one of them. This is not a bug, but a limitation of the filesystem you are using.

On FAT there is no difference bettwen 'file', 'File', 'FiLe', and all possible combinations of upper and lower case.

Closing invalid.

[C de-Avillez (hggdh2)]

By the way, the output on you last command only shows ' permission denied' errors.

seasoned_geek, I am not trying to be precious, or picky. I am just pointing the reason why case-sensitive copies may fail on FAT systems. I am also sorry it took that long for us to reach your bug. Please keep in mind that *most* of the work here is done by the community.

[Roland Hughes (original-seasoned-geek)]

You are completely overlooking the fact this error first occurred with Dolphin. On a name collision of any kind Dolphin is supposed to offer rename/overwrite. This didn't happen. Then I tested with CP (which should, if written correctly, offer the same options rather than failing).

>Please keep in mind that *most* of the work here is done by the community.

Please keep in mind that Ubuntu, in particular, is marketing itself to businesses for both desktop and server mode, therefore, a one year lag on an LTS issue is inexcusable under those circumstances.

[C de-Avillez (hggdh2)]

On 03/03/2011 10:25 AM, seasoned_geek wrote:
> You are completely overlooking the fact this error first occurred with
> Dolphin. On a name collision of any kind Dolphin is supposed to offer
> rename/overwrite. This didn't happen.

In this case, then we should reset the package on this bug to Dolphin.

> Then I tested with CP (which
> should, if written correctly, offer the same options rather than
> failing).

No. 'cp' is working correctly. The issue here is for 'cp' these are
different files, while for the filesystem they are the same. So 'cp'
is trying to create the file, and cannot.

[Roland Hughes (original-seasoned-geek)]

>No. 'cp' is working correctly. The issue here is for 'cp' these are
>different files, while for the filesystem they are the same. So 'cp'
>is trying to create the file, and cannot.

CP is not correctly handling the error. Period. Try it with
interactive and see how it works.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol
reserves.

On Thu, 2011-03-03 at 22:00 +0000, C de-Avillez wrote:

> No. 'cp' is working correctly. The issue here is for 'cp' these are
> different files, while for the filesystem they are the same. So 'cp'
> is trying to create the file, and cannot.