Date: Sat, 8 Jun 2002 13:18:51 -0700 (PDT) From: Evgeny zislis <kesor@ulp.co.il> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/39043: Corrupted files on a FAT32 partition Message-ID: <200206082018.g58KIptL011937@www.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 39043
>Category: kern
>Synopsis: Corrupted files on a FAT32 partition
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Jun 08 13:20:05 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Evgeny zislis
>Release: FreeBSD 4.6-RC
>Organization:
>Environment:
FreeBSD finone.ulp.co.il 4.6-RC FreeBSD 4.6-RC #4: Fri May 24 18:24:45 IDT 2002 kesor@finone.km.dshapiro.org:/usr/obj/usr/src/sys/FINONE i386
>Description:
I have a WDC 80G hard drive, one primarly dos partition formatted as FAT32. It is mounted as /storage. I am using samba (2.2.4_1) to share this directory to windows machines on the network.
Copying files from and to this partition works good,
using smbclient 'get' command to get files from remote machines and put them in the shared mount point with the samba protocol doesnt do any problems.
On another UFS partition samba has no problems, it only occures with the case of FAT32 partition. (thus why samba people tell me its not a samba issue, but rather msdosfs kernel module bug)
The problem occures when using a windows machine, to copy files to the shared storage folder via the network. When using \\machinename\storage in windows and writing to it - some parts of the file get overriden with 0roes.
I have used a 16mb file of random data, and from the hex dump its almost always more or less the same areas that are overriden with zeroes on the copied file :
080000-084000
100000-104000
180000-184000
200000-204000
280000-284000
d20000-end of file 1000000
I tested it in two completely different environments and networks, with completely different hardware and software that loosly matches my own configuration -- the problem repeats itself.
>How-To-Repeat:
80G hard drive, formatted as FAT32, mounted as msdosfs in FreeBSD.
samba port (2.2.4_1) installed and configured to share that mount point over the network.
Take a file (the bigger the better, 10 bytes file didnt corrupt, while 3mb mp3s were getting corrupt 100% of the time)
Using a windows machine, open the shared samba mount and copy a file to it, then check it with md5 to see that it's changed.
>Fix:
No known fix. there is a clue though,
in /sys/msdosfs_vnops.c : line 708
* If the offset we are starting the write at is beyond the end of
* the file, then they've done a seek. Unix filesystems allow
* files with holes in them, DOS doesn't so we must fill the hole
* with zeroed blocks.
if (uio->uio_offset > dep->de_FileSize) {
error = deextend(dep, uio->uio_offset, cred);
the bug is possible hiding in deextend or somewhere around it.
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206082018.g58KIptL011937>