Bug 265839 - Dolphin has problems counting and copying files from NTFS partitions
Summary: Dolphin has problems counting and copying files from NTFS partitions
Status: RESOLVED DUPLICATE of bug 238424
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.6
Platform: Ubuntu Linux
: NOR major
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 295773 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-08 20:53 UTC by Alvaro Manuel Recio Perez
Modified: 2012-09-28 18:59 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
kio bad counts files in large folder on NTFS partition (76.73 KB, image/png)
2011-10-30 10:48 UTC, Dambaev Alexander
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alvaro Manuel Recio Perez 2011-02-08 20:53:59 UTC
Version:           unspecified (using KDE 4.6.0) 
OS:                Linux

It seems as if Dolphin is unable to correctly count the files inside a folder when it is in an NTFS partition. Related to this, Dolphin also copies the wrong number of files from folders in NTFS partitions.

Reproducible: Always

Steps to Reproduce:
1. Locate in Dolphin a folder with a large number of files in an NTFS partition.
2. Select the folder and open its properties dialog.
3. Wait until Dolphin calculates its number of files and subfolders.
4. Press update and wait until it calculates the number of files again.

Actual Results:  
When the folder has the "right" number of files to trigger the bug (around 7000 in my tests) Dolphin shows a different file count everytime it is updated by clicking the corresponding button in the properties dialog (in my case, it varies between 1000 and 5000).

Aditionally, if that folder is copied, Dolphin will actually copy a different number of files everytime. This is especially dire as it can easily lead to data loss.

Expected Results:  
Dolphin should show the correct number of files everytime. It should also correctly copy all files.

OS: Linux (x86_64) release 2.6.35-25-generic
Compiler: cc
Comment 1 Dawit Alemayehu 2011-05-08 23:12:00 UTC
Are you sure this is not a driver related problem ? Did you attempt to copy the same folder from the command line after mounting the parition ?
Comment 2 Dawit Alemayehu 2011-05-09 00:25:50 UTC
I cannot duplicate this on Windows XP NTFS partition on the same hard drive:

1.) Copied a rather large folder with 575 files and 40 sub-folders (323 MB) to an ext4 partition and every folder and file copied fine.

2.) No matter how many times I press refresh on the properties dialog, I get the same information each and every time.

The only thing that is different is, on the mounted NTFS partition the directories have a size of 0 and hence the total size reported for the same folder on the NTFS partition and the same folder on the ext4 partition are different. However, that is also true on the command line as well ; so like I said you have to validate whether or not this issue is driver related since NTFS partitions on most Linux distributions are mounted using fuse.



the incorrect number of files being copied. I copied a directory containing 575 files and 40 sub-folders and it all completed fine. Also not matter how many times I refresh the size on
Comment 3 Alvaro Manuel Recio Perez 2011-05-10 01:11:30 UTC
It seems the behaviour has changed in the latest version of Dolphin (KDE SC 4.6.3). I've also upgraded to Kubuntu 11.04, so that could also account for the change.

Now, if I mount the NTFS partition with the folder and open its properties, the first time Dolphin stops counting very early, giving wrong results (between 1000 and 5000 files as in the original report). Then, after that, every time the count is updated Dolphin gives the right answer: 11935 files and 2640 subfolders. Unmounting and mounting the partition again leads to the wrong results the first time, and correct counts after that.

After reading your comments I tried something different: running "du" on the folder from command line just after mounting the partition and then opening the properties dialog in Dolphin seems to solve the problem. "du" always gives the same result and Dolphin's count of files and folders is correct every time.

I can consistently reproduce this bug so please, let me know if I can do something else to help.

Tomorrow, if I have time, I'll run some tests by copying this folder. I'll try to copy the folder both ways: just after mounting the partition and after running "du", to see if the behaviour is different.
Comment 4 Alvaro Manuel Recio Perez 2011-05-15 17:40:01 UTC
Sorry, I've been busy so it took me some days until I could do new tests.

I can confirm that Dolphin somehow doesn't see all the files when the partition is just mounted. I tried to copy the folder just after mounting to an ext4 partition and the copy wasn't complete. Looking at the properties of the original folder showed an incorrect number of files but, after refreshing, Dolphin gave the correct count. Copying the same folder on top of the previous partial copy worked and, in the end, the two folders were identical.

Next, I unmounted and remounted the same partition and this time I run "du" on the folder before copying. This time, the copy was successful and both folders were identical, with the correct file count.
Comment 5 Dambaev Alexander 2011-10-30 10:48:12 UTC
Created attachment 65038 [details]
kio bad counts files in large folder on NTFS partition
Comment 6 Dambaev Alexander 2011-10-30 10:49:52 UTC
confirm!
I have a folder on NTFS partition, that contains 10501 files with 290 sub directories. 
I've used krusader about 10 times to copy that folder to another locations (on NTFS and EXT4 partitions) and always it had been copied with different file count (3000-4000) and subfolders (179 at last time). 

At the same time, without remounting partition or something else, copying that folder with Midnight Commander and GNOME Commander, is always results right files' and subfolders count.

"mount" output:

~$ mount | grep /media
/dev/sdb1 on /media/data type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
~$ mount | grep /mnt
/dev/sda11 on /mnt/localdata type xfs (rw)


I've attached screen (attach id #65038) of "preinstall" folder properties dialogs.
1) /media/data/@os - is the source path, from where I copied folder "preinstall". NTFS partition. Left top and left bottom dialogs are belongs to the same folder, but showes different values.

2) /mnt/localdata/tmp1 - is the destination folder, in which I've copied "preinstall" folder using krusader. XFS partition. Top right screen showes only 4833 files and 176 folders in resulted folder, after copy.

3) /mnt/localdata/tmp - is the destination folder, in which I've copied "preinstall" folder using Midnight Commander. XFS partition. Krusader's (or kio's) folder properties dialog showes right values on the same folder, but on other-FS partition, copied with non-kde tool.
Comment 7 Dambaev Alexander 2011-10-30 10:58:37 UTC
and, if it is important: I am using Debian Testing

$ kioclient --version
Qt: 4.7.3
KDE Development Platform: 4.6.5 (4.6.5)
KIO Client: 2.0

$ krusader --version
Qt: 4.7.3
KDE Development Platform: 4.6.5 (4.6.5)
Krusader: 2.3.0-beta1 "New Horizons"

WM: Enlightenment DR17
Comment 8 Eugene Shtokolov 2011-11-09 08:13:47 UTC
I confirm the bug. Tested on:
- KDE 3.5.10 release 21.9, OpenSUSE 11.1 i686 liveCD
- KDE 4.7.3, chakra 2011.11.03 i686 liveCD
- KDE 4.7.3  release 10, OpenSUSE 11.4 x86_64 installed
I copied the Windows XP CD content into the NTFS partition on USB HDD. After I copied this folder into other on same partition.
Maybe it depend on amount of files. I removed some files from i386 folder (there a 4523 files) - bug occurs once in ten times. I removed all subfolders from i386 - bug left, then I created a single folder with an arbitrary name ('1' for example) - bug returned.

I'm sorry for my English.
Comment 9 Dawit Alemayehu 2012-08-13 15:37:27 UTC
*** Bug 295773 has been marked as a duplicate of this bug. ***
Comment 10 Dawit Alemayehu 2012-09-28 18:59:34 UTC

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