From dk@raven.plab.ku.dk  Wed Jan 29 03:26:19 2003
Return-Path: <dk@raven.plab.ku.dk>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5404437B401
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 29 Jan 2003 03:26:19 -0800 (PST)
Received: from raven.plab.ku.dk (raven.plab.ku.dk [130.225.107.27])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 46DCB43F85
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 29 Jan 2003 03:26:18 -0800 (PST)
	(envelope-from dk@raven.plab.ku.dk)
Received: from raven.plab.ku.dk (localhost [127.0.0.1])
	by raven.plab.ku.dk (8.12.6/8.12.6) with ESMTP id h0TBQB03001354
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 29 Jan 2003 12:26:11 +0100 (CET)
	(envelope-from dk@raven.plab.ku.dk)
Received: (from dk@localhost)
	by raven.plab.ku.dk (8.12.6/8.12.6/Submit) id h0TBQAPR001353;
	Wed, 29 Jan 2003 12:26:10 +0100 (CET)
Message-Id: <200301291126.h0TBQAPR001353@raven.plab.ku.dk>
Date: Wed, 29 Jan 2003 12:26:10 +0100 (CET)
From: Dmitry Karasik <dmitry@karasik.eu.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: msdosfs file corruption fix
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         47628
>Category:       kern
>Synopsis:       [msdosfs] [patch] msdosfs file corruption fix
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kib
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 29 03:30:01 PST 2003
>Closed-Date:    Thu Sep 04 15:11:15 UTC 2008
>Last-Modified:  Thu Sep 04 15:11:15 UTC 2008
>Originator:     Dmitry Karasik
>Release:        FreeBSD 4.7-STABLE i386
>Organization:
>Environment:
System: FreeBSD raven.plab.ku.dk 4.7-STABLE FreeBSD 4.7-STABLE #30: Wed Jan 29 11:07:09 CET 2003 root@raven.plab.ku.dk:/usr/obj/usr/src/sys/RAVEN i386


>Description:

        MSDOSFS does not support file holes, and when application writes beyound
        the end of file, pads the gap with zeroes. Under certain conditions
        this does not happen, - the files either filled with junk, or neighbor
        files get corrupted.

        I observed the bug on FAT32 partitions, 4GB and 57GB on two machines
        with 4.7-STABLE. I didn't observe the bug on FAT32 partitions on 4.3-STABLE.

>How-To-Repeat:

        The following perl script, if run on msdosfs, writes 10 files filled with
        an unique character. The files 0, 1, 2, 3, 4 are either filled with junk at 
        at the end, or random zero chunks are present in the middle of file. In the 
        latter case the script prints "inconsistency at ... " message.

        
            use strict;

            my $i;

            my $space = 5000000;
            my $maxfd = 10;
            my $use_nofd = 1;
            $|=1;
            print "init\n";

            my $ufdlim = $use_nofd ? int( $maxfd/2) : ($maxfd-1);

            for ( $i = 0; $i < $maxfd; $i++) {
               open F, "> $i";
               my $c = ($i) x 0;
               print F $c;
               close F;
            }

            eval "open F$_, qq(+< $_)" for 0 .. $ufdlim;

            print "start\n";

            my $t = 0;

            while ( 1) {
               my $fno  = int rand $maxfd;
               my $size = int rand ( $space / 100) + 1;

               my $fn;
               if ( $fno <= $ufdlim) {
                  $fn = eval "*F$fno";
               } else {
                  $fn = \*F;
                  open F, "+< $fno" or die "Error on $fno:$!\n";
                  sysseek F, 0, 2 or die "is:$!\n";
               }
               $size = 1024;

               $t += $size;

               my $sc = ( substr($fno,-1,1)) x $size;
               print int($t*100/$space/$maxfd), "%\r";
               sysseek $fn, 2047, 1 or die "seek $fno:$!";
               syswrite $fn, "X" or die "write $fno:$!";
               sysseek $fn, -2048, 1 or die "Seek $fno:$!";
               syswrite $fn, $sc or die "Write $fno:$!";
               close F if $fno >= $ufdlim;
               last if $fn <= $ufdlim && -s $fno > $space;
            }

            eval "close F$_;" for 0 .. $ufdlim;

            print "test\n";

            my $bigp = 0;
            for ( $i = 0; $i <= $ufdlim; $i++) {
               open F, "< $i";
               my $size = -s $i;
               my $lsize = $size - 2048 - 10240;
               my $sz;
               my $r;
               my $pos = 0;
               my $ss = substr($i,-1,1);

               my $rd = 10240;
               
               while (( $sz = sysread (F, $r, $rd)) > 0) {
                  my $str = ($ss) x $sz;
                  warn sprintf("$i inconsistent at %08x\n", $pos) if $r ne $str; 
                  $pos += $sz;
                  $bigp += $sz;
                  print int( $bigp * 100 / $size / $maxfd), "%\r";
                  if ( $lsize >= 10240) {
                     $lsize -= 10240;
                  } elsif ( $lsize == 0) {
                     last;
                  } else {
                     $rd = $lsize; 
                     $lsize = 0;
                  }
               }
               close F;
            #   unlink $i;
            }

            print "done\n";

>Fix:

	Since the corruption does not happen when files are written without seek-over-eof,
        it seems that the zero-padding code in MSDOSFS is faulty. The patch with more
        thorough explanation follows, but it would be necessary for someone with knowledge
        of msdosfs and vfs look at it first. Since the code didn't change after 1997, I
        believe it is some bsd-specific bio/vfs changes that triggered the bug.

        
--- msdosfs_fat.c	Wed Jan 29 11:58:46 2003
+++ /usr/src/sys/msdosfs/msdosfs_fat.c	Wed Jan 29 11:27:47 2003
@@ -1092,7 +1092,7 @@
 					*bpp = bp;
 					bpp = NULL;
 				} else
-					bdwrite(bp);
+					bwrite(bp);
 			}
 		}
 	}


--- msdosfs_vnops.c	Wed Jan 29 11:58:46 2003
+++ /usr/src/sys/msdosfs/msdosfs_vnops.c	Wed Jan 29 11:36:23 2003
@@ -710,11 +710,45 @@
 	 * files with holes in them, DOS doesn't so we must fill the hole
 	 * with zeroed blocks.
 	 */
+        /*
+
+        This code below was commented after it was noticed that writing beyond 
+        a file produces random corruption of the current file and its neighbors. 
+        This does not happen with regular file extension though. Example code
+
+           seek( f, 2047, SEEK_END); 
+           write( f, x, 1);
+           seek( f, -2048, SEEK_END);
+           write( f, x, 1024);
+
+        repeated simultaneously on several files leaves random garbage in the end
+        of some files, which points either on a race in FAT cluster allocation code,
+        or/and that the zero chunks that suppose to fill the gap were written to
+        a wrong place.
+        
+        The probable cause is that deextend() calls extendfile(.., DE_CLEAR),
+        which flushes zeroed blocks by bdwrite(). The patch reverts it to
+        bwrite() instead, and calls extendfile() directly. Since deextend() also
+        invokes deupdat(), it is probably a place where a race could occur, so
+        this is another reason to call extendfile() directly.
+
+        OTOH I do not know if it is o.k. not to update de_FileSize as dextend()
+        does, or probably vnode_pager_setsize() call must be done also. Although
+        it seems that the patch fights the corruptions, and ever if it does 
+        successfully, I believe the patch must be reviewed by someone who has
+        deeper knowledge of kernel, primarily because the corruptions were noticed
+        on 4.7-STABLE, but not on 4.3-STABLE, so I presume some changes in vfs
+        influenced msdosfs.
+
+        Dmitry Karasik, <dmitry@karasik.eu.org>
+        29.01.2003
+
 	if (uio->uio_offset > dep->de_FileSize) {
 		error = deextend(dep, uio->uio_offset, cred);
 		if (error)
 			return (error);
 	}
+        */
 
 	/*
 	 * Remember some values in case the write fails.
@@ -726,6 +760,14 @@
 	 * If we write beyond the end of the file, extend it to its ultimate
 	 * size ahead of the time to hopefully get a contiguous area.
 	 */
+	if (uio->uio_offset > dep->de_FileSize) {
+		count = de_clcount(pmp, uio->uio_offset + resid) -
+			de_clcount(pmp, osize);
+		error = extendfile(dep, count, NULL, NULL, DE_CLEAR);
+		if (error &&  (error != ENOSPC || (ioflag & IO_UNIT)))
+			goto errexit;
+		lastcn = dep->de_fc[FC_LASTFC].fc_frcn;
+	} else
 	if (uio->uio_offset + resid > osize) {
 		count = de_clcount(pmp, uio->uio_offset + resid) -
 			de_clcount(pmp, osize);


>Release-Note:
>Audit-Trail:

From: Dmitry Karasik <dmitry@karasik.eu.org>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc:  
Subject: Re: kern/47628: msdosfs file corruption fix
Date: Wed, 29 Jan 2003 15:56:23 +0100

 FreeBSD-gnats-submit@FreeBSD.org wrote:
 
 > Thank you very much for your problem report.
 > It has the internal identification `kern/47628'.
 > The individual assigned to look at your
 > report is: freebsd-bugs.
 >
 > You can access the state of your problem report at any time
 > via this link:
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=47628
 
 The link doesn't work somehow:
 
 </dl><A 
 HREF="mailto:freebsd-gnats-submit@FreeBSD.org,?subject=Re:%20/:%20">Submit 
 Followup</A> | <A HREF="./query-pr.cgi?pr=47628&amp;f=raw">Raw PR</A>
 <hr><address><a href="../mailto.html">www@FreeBSD.org</a><br></address>
 
 is the only information returned.
 
 /Dmitry
 
 
 

From: Peter Pentchev <roam@ringlet.net>
To: Dmitry Karasik <dmitry@karasik.eu.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/47628: msdosfs file corruption fix
Date: Wed, 29 Jan 2003 17:16:50 +0200

 On Wed, Jan 29, 2003 at 03:56:23PM +0100, Dmitry Karasik wrote:
 > 
 > 
 > FreeBSD-gnats-submit@FreeBSD.org wrote:
 > 
 > >Thank you very much for your problem report.
 > >It has the internal identification `kern/47628'.
 > >The individual assigned to look at your
 > >report is: freebsd-bugs.
 > >
 > >You can access the state of your problem report at any time
 > >via this link:
 > >
 > >http://www.freebsd.org/cgi/query-pr.cgi?pr=47628
 > 
 > The link doesn't work somehow:
 > 
 > </dl><A 
 > HREF="mailto:freebsd-gnats-submit@FreeBSD.org,?subject=Re:%20/:%20">Submit 
 > Followup</A> | <A HREF="./query-pr.cgi?pr=47628&amp;f=raw">Raw PR</A>
 > <hr><address><a href="../mailto.html">www@FreeBSD.org</a><br></address>
 > 
 > is the only information returned.
 
 This has happened to me, too, sometimes; try reloading the page, usually
 the second attempt does it :)
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net	roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 This sentence no verb.

From: Dmitry Karasik <dmitry@karasik.eu.org>
To: freebsd-gnats-submit@FreeBSD.org, dmitry@karasik.eu.org
Cc:  
Subject: Re: kern/47628: msdosfs file corruption fix
Date: Wed, 29 Jan 2003 17:34:43 +0100

 Correction about 4.3-STABLE - the bug is also there.
 Tested on 6G and 20G FAT32 partitions.
 
    Dmitry Karasik
 
Responsible-Changed-From-To: freebsd-bugs->trhodes 
Responsible-Changed-By: trhodes 
Responsible-Changed-When: Fri Dec 5 21:47:48 PST 2003 
Responsible-Changed-Why:  
This is something I would like to investigate. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47628 

From: Derek <derekm.nospam@rogers.com>
To: bug-followup@FreeBSD.org, dmitry@karasik.eu.org
Cc:  
Subject: Re: kern/47628: [msdosfs] [patch] msdosfs file corruption fix
Date: Mon, 24 Oct 2005 20:38:20 -0400

 I have verified that this issue affects 6.0-RC1.  I have applied the 
 patch to 6.0-RC1, and it does not fix the issue.  It may be worth noting 
 that this PR exhibits the same symptoms as kern/39043.

From: Derek <derekm.nospam@rogers.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/47628: [msdosfs] [patch] msdosfs file corruption fix
Date: Tue, 25 Oct 2005 10:12:52 -0400

 This is a multi-part message in MIME format.
 --------------030803020307090404050402
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Just for completeness, the patches that I applied are attached (same as 
 above, with different offsets).  Also I'd like to correct the above 
 phrase "the same symptoms" to "similar symptoms."
 
 --------------030803020307090404050402
 Content-Type: text/x-patch;
  name="msdosfs_fat.c.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="msdosfs_fat.c.patch"
 
 --- msdosfs_fat.c.orig	Thu Jan  6 13:10:38 2005
 +++ msdosfs_fat.c	Wed Oct 19 22:59:39 2005
 @@ -1104,7 +1104,7 @@
  					*bpp = bp;
  					bpp = NULL;
  				} else
 -					bdwrite(bp);
 +					bwrite(bp);
  			}
  		}
  	}
 
 --------------030803020307090404050402
 Content-Type: text/x-patch;
  name="msdosfs_vnops.c.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="msdosfs_vnops.c.patch"
 
 --- msdosfs_vnops.c.orig	Sun Feb 27 16:16:26 2005
 +++ msdosfs_vnops.c	Thu Oct 20 00:14:54 2005
 @@ -685,28 +685,28 @@
  		return (EFBIG);
  
  	/*
 -	 * 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);
 -		if (error)
 -			return (error);
 -	}
 -
 -	/*
  	 * Remember some values in case the write fails.
  	 */
  	resid = uio->uio_resid;
  	osize = dep->de_FileSize;
  
  	/*
 +	 * 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 we write beyond the end of the file, extend it to its ultimate
  	 * size ahead of the time to hopefully get a contiguous area.
  	 */
 -	if (uio->uio_offset + resid > osize) {
 +	if (uio->uio_offset > dep->de_FileSize) {
 +		count = de_clcount(pmp, uio->uio_offset + resid) -
 +			de_clcount(pmp, osize);
 +		error = extendfile(dep, count, NULL, NULL, DE_CLEAR);
 +		if (error &&  (error != ENOSPC || (ioflag & IO_UNIT)))
 +			goto errexit;
 +		lastcn = dep->de_fc[FC_LASTFC].fc_frcn;
 +	} else if (uio->uio_offset + resid > osize) {
  		count = de_clcount(pmp, uio->uio_offset + resid) -
  			de_clcount(pmp, osize);
  		error = extendfile(dep, count, NULL, NULL, 0);
 
 --------------030803020307090404050402--
State-Changed-From-To: open->feedback 
State-Changed-By: kmacy 
State-Changed-When: Fri Nov 16 07:06:10 UTC 2007 
State-Changed-Why:  

Please comment on whether this is still an issue that needs to be addressed. 


Responsible-Changed-From-To: trhodes->bde 
Responsible-Changed-By: kmacy 
Responsible-Changed-When: Fri Nov 16 07:06:10 UTC 2007 
Responsible-Changed-Why:  

Please comment on whether this is still an issue that needs to be addressed.  

http://www.freebsd.org/cgi/query-pr.cgi?pr=47628 

From: Tor Egge <Tor.Egge@cvsup.no.freebsd.org>
To: freebsd-gnats-submit@freebsd.org
Cc: freebsd-bugs@freebsd.org, bde@freebsd.org, kib@freebsd.org
Subject: Re: kern/47628: msdosfs file corruption fix
Date: Wed, 27 Aug 2008 20:14:47 +0000 (UTC)

 ----Next_Part(Wed_Aug_27_20_14_47_2008_639)--
 Content-Type: Text/Plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 
 I recently stumbled onto the same issue when setting up a backup disk with a
 msdosfs scratch area for transfer of files.  I used rsync with the 'S' option
 to copy the files to the FAT32 file system, resulting in corrupted blocks.  The
 cluster size was 32K.
 
 Looking at the badness in a file, blocks 5 and 6 contained NULs instead of the
 correct file data.  Those were the only blocks where the first byte should be a
 NUL.
 
 A few extra debug messages in the file system code (e.g. in msdosfs_strategy)
 when reproducing the problem showed that blocks 5 and 6 were correctly written,
 but later blocks 320 and 384 were written to the same location with NULs.  The
 file was 319488 bytes long, and should only have blocks in the range [0..9].
 
 This problem seems to have been introduced in revision 1.17 of
 src/sys/fs/msdosfs/msdosfs_fat.c, where file relative cluster numbers were
 replaced by file relative sector numbers as the buffer block number when
 zero-padding a file during extension.
 
 With the enclosed patch applied, I no longer got corrupted files, but I 
 only tested with clustering disabled, using 
 
   mount -t msdosfs -o large -o noclusterr -o noclusterw /dev/da6s1 /mnt
 
 to mount the file system.
 
 As an alternative to initializing nvp->v_bufobj.bo_bsize to the cluster size
 for regular files, mp->mnt_stat.f_iosize could be initialized to the cluster
 size in mountmsdosfs().  The cluster size would then be copied to new vnodes in
 getnewvnode().
 
 - Tor Egge
 
 ----Next_Part(Wed_Aug_27_20_14_47_2008_639)--
 Content-Type: Text/Plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline; filename="msdosfs.diff2"
 
 Index: sys/fs/msdosfs/msdosfs_denode.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v
 retrieving revision 1.99
 diff -u -r1.99 msdosfs_denode.c
 --- sys/fs/msdosfs/msdosfs_denode.c	24 Jan 2008 12:34:26 -0000	1.99
 +++ sys/fs/msdosfs/msdosfs_denode.c	26 Aug 2008 04:52:06 -0000
 @@ -163,6 +163,8 @@
  	}
  	bzero((caddr_t)ldep, sizeof *ldep);
  	nvp->v_data = ldep;
 +	if ((ldep->de_Attributes & ATTR_DIRECTORY) == 0)
 +		nvp->v_bufobj.bo_bsize = pmp->pm_bpcluster;
  	ldep->de_vnode = nvp;
  	ldep->de_flag = 0;
  	ldep->de_dirclust = dirclust;
 Index: sys/fs/msdosfs/msdosfs_fat.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_fat.c,v
 retrieving revision 1.49
 diff -u -r1.49 msdosfs_fat.c
 --- sys/fs/msdosfs/msdosfs_fat.c	25 Oct 2007 08:23:08 -0000	1.49
 +++ sys/fs/msdosfs/msdosfs_fat.c	26 Aug 2008 04:09:26 -0000
 @@ -1065,13 +1065,13 @@
  					    pmp->pm_bpcluster, 0, 0, 0);
  				else {
  					bp = getblk(DETOV(dep),
 -					    de_cn2bn(pmp, frcn++),
 +						    frcn++,
  					    pmp->pm_bpcluster, 0, 0, 0);
  					/*
  					 * Do the bmap now, as in msdosfs_write
  					 */
  					if (pcbmap(dep,
 -					    de_bn2cn(pmp, bp->b_lblkno),
 +						   bp->b_lblkno,
  					    &blkno, 0, 0))
  						bp->b_blkno = -1;
  					if (bp->b_blkno == -1)
 
 ----Next_Part(Wed_Aug_27_20_14_47_2008_639)----
Responsible-Changed-From-To: bde->kib 
Responsible-Changed-By: kib 
Responsible-Changed-When: Mon Sep 1 09:36:26 UTC 2008 
Responsible-Changed-Why:  
tegge@ submitted the fix, will commit it shortly. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47628 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/47628: commit references a PR
Date: Mon,  1 Sep 2008 13:18:36 +0000 (UTC)

 kib         2008-09-01 13:18:16 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/fs/msdosfs       msdosfs_fat.c 
   Log:
   SVN rev 182600 on 2008-09-01 13:18:16Z by kib
   
   In rev. 1.17 (r33548) of msdosfs_fat.c, relative cluster numbers were
   replaced by file relative sector numbers as the buffer block number when
   zero-padding a file during extension. Revert the change, it causes wrong
   blocks filled with zeroes on seeking beyond end of file.
   
   PR:     kern/47628
   Submitted by:   tegge
   MFC after:      3 days
   
   Revision  Changes    Path
   1.50      +2 -2      src/sys/fs/msdosfs/msdosfs_fat.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/47628: commit references a PR
Date: Thu,  4 Sep 2008 14:25:27 +0000 (UTC)

 kib         2008-09-04 14:25:10 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_7)
     sys/fs/msdosfs       msdosfs_fat.c 
   Log:
   SVN rev 182756 on 2008-09-04 14:25:10Z by kib
   
   MFC r182600:
   In rev. 1.17 (r33548) of msdosfs_fat.c, relative cluster numbers were
   replaced by file relative sector numbers as the buffer block number
   when zero-padding a file during extension. Revert the change, it causes
   wrong blocks filled with zeroes on seeking beyond end of file.
   
   PR:     kern/47628
   Approved by:    re (kensmith)
   
   Revision  Changes    Path
   1.48.2.1  +2 -2      src/sys/fs/msdosfs/msdosfs_fat.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/47628: commit references a PR
Date: Thu,  4 Sep 2008 15:09:55 +0000 (UTC)

 kib         2008-09-04 15:09:26 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sys/fs/msdosfs       msdosfs_fat.c 
   Log:
   SVN rev 182759 on 2008-09-04 15:09:26Z by kib
   
   MFC r182600:
   In rev. 1.17 (r33548) of msdosfs_fat.c, relative cluster numbers were
   replaced by file relative sector numbers as the buffer block number
   when zero-padding a file during extension. Revert the change, it causes
   wrong blocks filled with zeroes on seeking beyond end of file.
   
   PR:     kern/47628
   Approved by:    re (kensmith)
   
   Revision  Changes    Path
   1.37.2.2  +2 -2      src/sys/fs/msdosfs/msdosfs_fat.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: feedback->closed 
State-Changed-By: kib 
State-Changed-When: Thu Sep 4 15:10:39 UTC 2008 
State-Changed-Why:  
Committed to RELENG_{6,7}. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47628 
>Unformatted:
