Bugzilla – Bug 150665
Konqueror does not recognize FAT case-insensitivity for a move/rename operation.
Last modified: 2006-03-08 13:55:02 UTC
The following will duplicate the "problem": 1. Create a file e.g. linux.odt 2. In Konqueror, do a rename of the file to capital letter, e.g. Linux.odt 3. A windows will pop up and ask for confirmation of over write. 4. Click to confirm 5. Both the files (linux.odt and Linux.odt) will be GONE (disappear). The file cannot be loaded in the entire system as a search for the filename turns up nothing. It also cannot be found in the "rubbish bin". As I do not have other linux loaded, am not able to confirm if this is a normal sympton for all distro.
Does this happen with other files at other locations, too? As you discribe it, Linux.odt already exists when you try this. What happens if the target file does not exist (yet)?
Another question: What filesystem do you use in this partition/directory? FAT?
Answer to comment #1: Target file exist as this was found while trying to rename a file to the same name but with Capital letter (e.g. from suse.odt to Suse.odt) As far as I can remember, renaming a file to another name (target file does not exist) isn't a problem, the renamed file will not disappear. I will try it latter just to confirm this point when with my computer and update if it is not so. ____ Answer to comment #2: You are right, filesystem is FAT as this is a dual boot. Will try to rename a file that exist in ext3 or reiserfs and update the status.
> Target file exist as this was found while trying to rename a file to the same > name but with Capital letter (e.g. from suse.odt to Suse.odt) Using FAT would explain this because FAT is case-insensitive. On the other hand it makes your renaming-approach useless. Does this work on a shell (xterm, kterm)? %mv suse.odt Suse.odt If it doesn't work there either, it's a problem with the filesystem implementation which is unlikely.
Follow-up on Comment #3: to comment #1: Renaming file to another name (target file does not exist), the file will not disappear. Note that all this is done in Konqueror. to comment #2: rename of file in FAT32 WILL cause the problem, file will disappear. rename of file in Reiserfs WILL NOT cause the problem. Reply to comment #4: in ext3 filesystem, using Konsole, the command mv test.odt Test.odt will rename the file and the file is present. in FAT filesystem, again using the same command will result in the message: mv: `test.odt' and `Test.odt' are the same file resulting in nothing changed. seems like the problem exist only in FAT32 filesystem and when using Konqueror to rename.
OK then we have narrowed this down. Indeed `mv' should not work in that fashion on an FAT-filesystem as this would really make no sense ;) We'll need help of the KDE-maintainers here, this, if not already done so, should at least be fixed for 10.1. If I should make a (not so) wild guess why this happens: Konqueror does not recognize that it tries to modify a FAT system and thinks it actually makes a move, then, by deleting the source file, it actually kills the target file... (Michal: Remember that a `mv' is indeed only a copy by a followed deletion in the general case). Raising to critical because this could result in data loss and unfortunately many (mobile) devices use FAT as a default.
I'm pretty sure we do have code to detect and solve such case. - can you rename the file using an intermediate name (i.e. two rename's) ? - what is the /etc/mtab line for that filesystem? - what is the directory location shown in Konqueror?
it works fine here on my 10.1 btw.
Lubos: A normal rename works (see comment #3) - the problem is that Konqueror obviously does not realize it's not making an actual rename here. I cannot test it because my test machine is broken at the moment, but I will try to reproduce this. Michal: Please provide the additional information asked for in comment #7
Answer to Comment #7 - yes, can rename the file using intermediate name. as to the other two, do not quite understand what you mean here, please elaborate. Answer to Comment #8 as I can afford only one computer (no test machine so have to be extra careful) :-( anyway, if there's a need, I will update to 10.1 once it goes into stable and test it out. please prompt me to update ;-)
BTW 1: I can't reproduce the bug with KDE 3.5.0 on SUSE 10.0 (supplementary packages), so I guess it was fixed in KDE 3.5. BTW 2: I guess KDE 3.4 does something like (in bash syntax) cp file File ; rm file while KDE 3.5 does cp file File && rm file BTW 3: Michal, you forgot to set the bug back to ASSIGNED...
Answer to Comment #11 BTW 1: okay, will try to install 10.1 stable and update all BTW 3: new to this, had assumed that reporting and providing info is all I need to do ...... Oops :^)
Comment #10: - attach your /etc/mtab and /etc/fstab to this bugreport (at the time you're browsing the directory where the problem happens) - location is the lineedit below Konqueror toolbar that says "location:", at the time of viewing this bugreport it should say "https://bugzilla.novell.com/show_bug.cgi?id=150665" Comment #11: - Unlikely and unlikely - the code doesn't seem to have changed in some time, so it seems to be specific to this setup.
Comment #13 cat /etc/fstab /dev/hdb6 / reiserfs acl,user_xattr 1 1 /dev/hda1 /windows/C vfat users,gid=users,umask=0002,utf8=true 0 0 /dev/hdb1 /windows/D vfat users,gid=users,umask=0002,utf8=true 0 0 /dev/hdb5 /windows/E vfat users,gid=users,umask=0002,utf8=true 0 0 /dev/hda4 swap swap defaults 0 0 /dev/hdb7 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 /dev/cdrecorder /media/cdrecorder subfs noauto,fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 /dev/fd0 /media/floppy subfs noauto,fs=floppyfss,procuid,nodev,nosuid,sync 0 0 cat /etc/mtab /dev/hdb6 / reiserfs rw,acl,user_xattr 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 devpts /dev/pts devpts rw,mode=0620,gid=5 0 0 /dev/hda1 /windows/C vfat rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true 0 0 /dev/hdb1 /windows/D vfat rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true 0 0 /dev/hdb5 /windows/E vfat rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true 0 0 usbfs /proc/bus/usb usbfs rw 0 0 /dev/fd0 /media/floppy subfs rw,nosuid,nodev,sync,fs=floppyfss,procuid 0 0 directory location shown in Konqueror media:/hda1/
It's the media:/ URL, the FAT rename check works only for local files. I cannot reproduce any data loss with KDE3.5 though, the rename eventually simply fails.
Ok, the data loss is in 10.0, but in 10.1 the rename silently fails without any data loss.
I can reproduce it on my 10.0 and I can't find a change in 3.5 that would fix it explicitly. So it might take a while - and I only have that 10.0 till friday ;)
I added an explicit check against renaming a file to itself. So the rename no longer fails silently - fixing this issue for sure. I won't submit an update though as the chances that one hits the bug is pretty small in my view (proven by no report about this problem on bugs.kde.org).