Bug 31692

Summary: 2872-or-less-byte ftp binary transfer from smbfs share produces garbage
Product: Base System Reporter: Doug Lee <dgl>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.3-STABLE   
Hardware: Any   
OS: Any   

Description Doug Lee 2001-11-01 15:50:00 UTC
Trying to ftp a short file from a mounted smbfs share using binary
mode will produce garbage in the garbage file instead of a copy of
the file being transferred.  The garbage varies from one attempt
to the next.  This occurs even when using "ftp localhost."  It does
not occur when transferring from a UFS mount or when transferring
in ASCII mode, or when the file is larger than 2872 bytes.  The
problem does not occur when accessing the smbfs-mounted file by
other means (e.g., ex/vi, cp, or even copying to a Windows box via
a Samba share).  tcpdump during the corrupted ftp shows that data
moves correctly from smbfs-mounted machine to FreeBSD but is
incorrect by the time it leaves FreeBSD (via ftpd) for its final
destination.  Reproduced on two machines running different 4.3-STABLE
snapshots.  Transfers using wu-ftpd-2.6.1 work properly.

Fix: 

Workaround: Copy the needed file via means other than ftp to a UFS
mount before getting it with FTP, or use a different ftpd.
How-To-Repeat: Mount a Windows share via smbfs, ftp localhost on the FreeBSD box,
log in and change to binary mode, and get a file of2872 bytes
or less from somewhere under the smbfs mount point.  Compare original
and transferred files.
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2001-12-27 12:45:13 UTC
State Changed
From-To: open->feedback

First, try a recent RELENG_4 and confirm that the problem persists. 

Then, my guess would be sendfile() ickiness.  We can prove this by 
forcing the use of the old method instead of sendfile(). 

In ftpd.c, in send_data(), find the first occurrence of 

if (isreg) { 

and insert 

goto oldway; 

immediately before it.  This will skip the sendfile() method.  If that 
solves the problem, we know it's odd sendfile() interaction with 
smbfs (or possibly all remote filesystem types).  If so, it'd 
be interesting to see whether the same behaviour is observed with 
NFS instead of smbfs.
Comment 2 Sheldon Hearn 2001-12-30 14:56:22 UTC
Followup confirming that the problem is sendfile(2)-specific.

Ciao,
Sheldon.

----- Original Message -----

Date:  Sun, 30 Dec 2001 15:47:45 +0100 (CET)
From:  Michal Mertl <mime@traveller.cz>
To:  Sheldon Hearn <sheldonh@starjuice.net>
cc:  current@freebsd.org
Subject:  Re: ntfs and sendfile problem (corrupted data) 


> On Sun, 30 Dec 2001, Sheldon Hearn wrote:
> 
> >
> >
> > On Sun, 30 Dec 2001 01:53:08 +0100, Michal Mertl wrote:
> >
> > > I have ntfs partition mounted ro on current. I can read from it without
> > > problems. But I noticed I get corrupted data (the corrupted file has
> > > right size but contains mostly zeros) when using ftpd to read them.
> > >
> > > I'm pretty sure the problem is thus in sendfile(2) and/or ntfs fs support.
> >
> > See also PR bin/31692, which reports simmilar problems using ftpd and
> > smbfs.  See my request for feedback, which ought to help verify that
> > it's sendfile(2) causing the problem.
> >
> 
> I did use the "goto oldway;" and the problem went away. I tried to look at
> /sys/kern/uipc_syscalls.c sendfile implementation but it is too complex
> for me :-(. I tried ktrace on ftpd but only saw the call to sendfile(2).
> If you give me some guidance I can try to look into problem deeper. I
> don't have any experience in kernel debugging but would like to learn it.
> 
> 
> 
> > Ciao,
> > Sheldon.
> >
> 
> -- 
> Michal Mertl
> mime@traveller.cz

>
Comment 3 Ceri Davies freebsd_committer freebsd_triage 2003-06-08 18:57:23 UTC
State Changed
From-To: feedback->open

Feedback has been requested and received; throw this PR back open.
Comment 4 Tim Robbins freebsd_committer freebsd_triage 2004-02-15 07:06:32 UTC
State Changed
From-To: open->closed

Same as kern/36038; closing this one as a duplicate because the 
newer PR has a more useful audit trail