After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 347457 - Nautilus fails without notification when copying files with similar names from ext3 to fat32
Nautilus fails without notification when copying files with similar names fro...
Status: RESOLVED DUPLICATE of bug 144726
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.14.x
Other All
: Normal critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-07-13 23:26 UTC by Maimon Mons
Modified: 2006-11-06 12:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Maimon Mons 2006-07-13 23:26:33 UTC
Please describe the problem:
The issue is that ext3 is a case-sensitive filesystem while fat32 is a case-retentive filesystem.

Nautilus doesn't realize that during the copy of multiple files from an ext3 partition to a fat32 partition, two files will be mapped to the same file name on the destination folder.

Steps to reproduce:
1. Setup 2 partitions. Partition1 should be ext3. Partition2 should be fat32.
2. Create 2 files in partition1 with the names filetobecopied and FileToBeCopied
3. Using nautlus, drag and drop the two files to a directory in Partition2.

Actual results:
One of the files will show up in Partition2.  Nautilus gives no indication that the other file is "lost".

Expected results:
One of the files gets copied over.  When trying to copy over the second file, nautilus brings up a user notification box giving him options on what to do:
A. Abort the copy process.
B. Overwrite the first file with the second file, continue copying any other files.
C. Give the second file a new name, continue copying any other files.

Does this happen every time?
Yes (!)

Other information:
This is a serious dataloss bug for the following reasons:
Many external hard drives and removable drives are fat32 for interoperability among Win9x/NT/XP, OS X, and Linux.

A user may copy over an entire directory tree from ext3 to the fat32 filesystem, believing he made a backup copy.

As for when this would come up for the average user:
Many digital cameras (particularly Canon models) assign photos with the name IMG_xxxx (where xxxx is a 4 digit number).  Other canon models (and possibly the same camera mounted on 2 different OSs assign photos with the name img_xxxx.
Comment 1 Maimon Mons 2006-07-14 00:13:38 UTC
One other thing that increases the severity of this bug:

In my steps to reproduce this bug, in steo 2, create the 2 files with similar names in the same directory as a lot of other files.  In step 3, drag all the files in the directory to the new drive.

You will notice that nautilus silently aborts the process!

I got bit by this because I had 2 files in a directory quite deep in my directory tree with similar names.  I copied the entire directory tree in nautilus, expecting the entire tree to be backed up.

Only when I tried to access the information on another date did I notice that a good number of the directories were not copied over!  (Serious dataloss :-( )
Comment 2 Mike Robinson 2006-09-05 16:35:48 UTC
Duplicated with Nautilus 2.14.1 copying from ext3 to vfat, also reiserfs to vfat.
Comment 3 Luke Hutchison 2006-09-05 22:35:51 UTC
The abort problem in comment #1 is described in bug 144726.  (I can also confirm this behavior.)  This should probably be marked as a dup of that bug.
Comment 4 Jimmy Angelakos 2006-09-19 20:01:08 UTC
I also confirm this behaviour on Nautilus 2.14.3-0ubuntu1. I agree that this is the same problem as bug 144726 and should be marked as duplicate.
Comment 5 Alexander Larsson 2006-11-06 12:35:23 UTC

*** This bug has been marked as a duplicate of 144726 ***