Szabolcs Szakacsits wrote: > On Fri, 25 Jan 2008, Diomidis Spinellis wrote: >> Szabolcs Szakacsits wrote: >>> On Thu, 24 Jan 2008, Diomidis Spinellis wrote: >>>> When I read large files using ntfs-3g 1.1120 the read is truncated. The >>>> problem does not occur with shorter files. >>> Thank you for the bug report. This looks to be a FreeBSD specific LFS (large >>> file support) issue. I can't reproduce it on Linux (1.2125-RC with >>> fuse-lite): >>> >>> % dd of=file seek=60011642880 bs=1 < /dev/null >>> % time dd if=file bs=1M >/dev/null >>> 57231+1 records in >>> 57231+1 records out >>> 60011642880 bytes (60 GB) copied, 296.022 seconds, 203 MB/s >> Just to make sure: are you sure you're not creating a sparse file with the >> first dd command? > > You caught me ;) > > The driver is tested with LFS files on Linux up to 3 TB (2TB is also a > common "magical" limit due to <most_common_sector_size> * 2^32) and I knew > simple writes must work too. The above example with a sparse file was a > "trick" to demonstrate no fundamental LFS problem on Linux and make it > possible to test the most common code paths on block devices without 60 GB > real free space. > > But the example indeed doesn't mean non-sparse files must also work. > > Could you please test the above? If it passes then the problem is probably > in FreeBSD's ntfs_pread() or UBLIO. It could be that config.h isn't > included somewhere, so off_t doesn't get defined 64-bit.
I tried to creat and read a largish file under FreeBSD with similar results (truncation). $ ntfs-3g ntfsfile /mnt dd if=/dev/zero of=large bs=1M count=18000 $ cd /mnt $ df . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/fuse0 20479996 66612 20413384 0% /mnt $ dd if=/dev/zero of=large bs=1M count=18000 18000+0 records in 18000+0 records out 18874368000 bytes transferred in 1362.057903 secs (13857243 bytes/sec) $ ls -l total 18432000 -rwxrwxrwx 1 root wheel 0 Jan 26 10:35 a -rwxrwxrwx 1 root wheel 18874368000 Jan 26 10:59 large $ dd if=large of=/dev/null bs=1M 1616+0 records in 1616+0 records out 1694498816 bytes transferred in 46.868849 secs (36154052 bytes/sec) I also tried to create the 60GB file you indicated, but the system crashed. (Note the file wouldn't normally fit on the disk's 3GB free space, but I hoped that it would be created in a sparse form.) I will be able to examine the machine's remains and logs on Monday, when I can go back to our lab. PS I'm using a patched version of fusefs-kmod, with a few changes I made in order to make it compile under the 8.0-CURRENT version of FreeBSD <http://www.freebsd.org/cgi/query-pr.cgi?pr=119944>. Diomidis ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
