Bug 85653 - wrong file size while copying large file from smb
Summary: wrong file size while copying large file from smb
Status: RESOLVED DUPLICATE of bug 97073
Alias: None
Product: kio
Classification: Unclassified
Component: smb (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
: 92765 96361 108055 127862 134787 134788 135393 136334 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-07-21 23:08 UTC by Michael Jahn
Modified: 2006-11-26 22:03 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screen Shot. (8.89 KB, image/png)
2004-07-21 23:09 UTC, Michael Jahn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Jahn 2004-07-21 23:08:14 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc 3.4.0 
OS:                Linux

When copying a large file from a smb share the size is not shown correctly after 2GB. Most likely an integer overflow. This is HEAD from today. Copying to a smb host works fine.

Host: Windows XP
libsmbclient 3.0.4

I will attach an image (in the hope it will work this time :-| ).
Comment 1 Michael Jahn 2004-07-21 23:09:09 UTC
Created attachment 6776 [details]
Screen Shot.
Comment 2 Stephan Kulow 2004-07-27 10:13:19 UTC
hmm, I thought that's fixed in 3.3
Comment 3 Thomas Bettler 2005-04-21 13:29:27 UTC
This may be in relation with the poor 2^32 bit limit for kio_smb.

See this bug: (seems to be duplicated)
http://bugs.kde.org/show_bug.cgi?id=92765
Comment 4 Thomas Bettler 2005-04-21 13:32:09 UTC
Same problem exists for kio_sftp: 
 http://bugs.kde.org/show_bug.cgi?id=103729 
Comment 5 Tommi Tervo 2005-05-12 11:00:06 UTC
*** Bug 92765 has been marked as a duplicate of this bug. ***
Comment 6 Maksim Orlovich 2005-06-24 15:15:29 UTC
*** Bug 108055 has been marked as a duplicate of this bug. ***
Comment 7 rene B 2005-07-18 20:23:23 UTC
I'm not sure this problem is samba related. It might be KDE or smb-kioslave related. This problem is also posted at KDE.  
Server is running mandrake 10.1, smbd 3.0.11. The server is exporting a share called hda containing a 6.3 GB file.
Client 1 is running mandrake 10.2, kde 3.3.2, smb4k 0.5.1., smbd 3.0.13.
When using smb4k for mounting the server, the filesize is reported as 6.3 GB (6.776.653.980 bytes). This is OK. When accessing the same share on the server using smb://user@server1/hda, the filesize is 2.3 GB (2.481.686.684 bytes). This is not OK.
Client 2 is running mandrake 10.1, kde 3.2.3, smb4k 0.4.0, smbd 3.0.13.
When using smb4k for mounting the server, the filesize is reported as 6.3 GB (6.776.653.980 bytes). This is OK. When accessing the same share on the server using smb://user@server1/hda, the filesize is 16.777.216.0 TB (18.446.744.071.896.270.848 bytes) This is not OK.
Comment 8 Oliver Doerr 2005-07-18 20:57:43 UTC
I don't believe that it is a samba related problem (at least not on my machine). The samba client shows me the right size, if i mount the same path manually using 

mount -t smbfs

and make ls -l. 
Comment 9 Thiago Macieira 2005-07-18 21:38:00 UTC
I'll debug when I have the chance.
Comment 10 rene B 2005-07-19 12:04:13 UTC
I did some additional tests. There seems to be a problem related to the client of samba. This problem is also reported on samba.org (id 2887).
Client is running mandrake 10.2, kde 3.3.2, smb 3.0.13. 
I made a share on the client, and mounted this share on the client itself 
using smb4k. 
In this share is an avi-file of 6.3 GB. I think it is not an old-type AVI-file 
because, as far as I understood, these have a filesize limit of 2 GB. It is an 
OpenDML AVI-file. The file is generated using kmenc15, which runs on top of 
the latetst plf-mencoder. 
An avi-file should have an index inside itself, because an index makes it 
possible to rapidly go forward and backward throuhg the file. 
The videoplayers I use are xine (latest plf) and vlc 0.8.2. 
When accessing the avi-file with vlc, and the avi-file is located on an ext3 
filesystem, vlc is able to "see" the duration of the file and is able to go 
fast forward and backward through the file. This does not generate cpuload, so 
it is apparently an easy thing to do for vlc. 
When accessing the same avi-file with vlc, and the avi-file is accessed by a 
mounted smb filesystem, vlc is not able to "see" the duration of the file and 
is not able to go fast forward and backward through the file. 
When accessing the same avi-file with xine, and the avi-file is accessed by a 
mounted smb filesystem, xine reports to me that it is restoring the index when 
going fast forward and backward through the file. This is very cpu-intensive 
and slow. 
When accessing the avi-file with xine, and the avi-file is located on an ext3 
filesystem, xine is able to go fast forward and backward through the file. 
As far as I understood, the index information is "somewhere" in de file, and 
because of compatible reasons with the old AVI-file spec's, it is located 
after the first 2 GB of data. 
Apparently seeking through a file when mounted using smb is not possible or is 
different compared with seeking through a the same file on a plain ext3 
filesystem. 
I upgraded samba from 3.0.13 t 3.0.14a but this does not change the behaviour. 
I think it is not player-related because xine and vlc do not share much code 
for reading files or decoding avi's (as far as I know). 
Using WXP gives a different result. A drive-letter is used on WXP to mounted 
the share on the Mandrake-PC. VLC 0.8.2 on WXP is able to show the duration of 
the avi-file and is able to go fast forward and backward. 
I went back to the mandrake-PC and did another mount of the same share. The 
first mount was done through smb4k. The second mount was done typing mount -t 
smbfs //mdktest/share /mnt/test -o=user. Typing ls -l shows the correct filesize.
The result did not differ from the results using smb4k. Vlc cannot report the 
duration of the avi-file. Xine still reports "restoring index" when going fast 
forward or backward. 
On the share is also another AVI with a filesize of 1.9 GB. Most likely this 
is an old-style AVI. VLC and Xine do not have any problem playing this file. 
These results suggest that the problem is not related to the server-part of 
samba but to the linux-client-part of samba and is related to the filesize. 
Being able to use the index inside an avi is important because of the ability 
of using the fast forward and backward buttons on the videoplayer.
Comment 11 Thiago Macieira 2005-08-15 04:39:00 UTC
Possibly related to bug 93544.
Comment 12 Thiago Macieira 2005-08-15 04:39:32 UTC
Uh, never mind. Wrong bug report.
Comment 13 Tommi Tervo 2005-08-22 12:29:59 UTC
*** Bug 96361 has been marked as a duplicate of this bug. ***
Comment 14 Tommi Tervo 2005-08-22 12:50:38 UTC
Still problem with KDE svn. 
kio_smb: smbc_stat smb://tomtervo@bigcrunch.ntc.nokia.com/tomtervo/bigfile 0 0
kio_smb: size 423624704

should be 4718592000
Comment 15 Nicolas Goutte 2005-09-19 01:24:17 UTC
See also bug #112850 (for Krusader)
Comment 16 Tommi Tervo 2006-05-23 09:57:18 UTC
*** Bug 127862 has been marked as a duplicate of this bug. ***
Comment 17 Dmitry S. Makovey 2006-06-08 07:09:52 UTC
KDE-3.5.2
samba-3.0.22
same problem. Transfering over 4G file progress bar goes nuts after passing over 2G mark.
Comment 18 Tommi Tervo 2006-09-28 16:02:30 UTC
*** Bug 134787 has been marked as a duplicate of this bug. ***
Comment 19 Tommi Tervo 2006-09-28 16:04:09 UTC
*** Bug 134788 has been marked as a duplicate of this bug. ***
Comment 20 石庭豐 2006-09-28 17:04:52 UTC
I'd just like to add that, even though the copy dialog displays wrong message, the copy process in background is going well.  If we're patient enough, the copy will eventually finish and the result file size is correct.  So, it's just a GUI problem.  I don't think it's Samba client problem (cf bug 134787).
Comment 21 Tommi Tervo 2006-10-10 15:17:47 UTC
*** Bug 135393 has been marked as a duplicate of this bug. ***
Comment 22 Tommi Tervo 2006-10-26 13:40:42 UTC
*** Bug 136334 has been marked as a duplicate of this bug. ***
Comment 23 Martin Koller 2006-11-26 22:03:45 UTC
filetransfer display fixed for files > 2 GB

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