Craig Shelley
2001-May-03 23:01 UTC
BUG FIX: SAMBA VFAT KERNEL 2.4.x & LARGE FILE SIZE > 90kb
I have had this crazy problem since i got 2.4.x
kernel.
I have a mounted VFAT partition with my mp3's on and i
wanted to share it with a windows computer. With
kernels 2.2.x, i had no problems reading and writing.
After upgrading kernel, i noticed that if i tried to
copy a file from the windows 95 machine to the linux
box, that was over about 100kb, i would get a access
denied error. I was baffled by this and posted aa
message onto this board, hoping that it would be
sorted out in the next version of samba.
I downloaded the latast releace of samba and kernel
2.4.4 and found the bug still existed. I have only
been learning c for about 2 weeks, and thought it
would be good learning experence to find this bug.
6 hours later, i found this...
In reply.c in the smbd dir of the source, there is a
function called reply_write
This is called when samba is requested to write a file
to a share.
using the method of placing loads of debug messages i
found that these commands check to make sure that the
data written to the file has actualy got there.
This is on line 2622 in the file smbd/reply.c
if(((nwritten == 0) && (numtowrite != 0))||(nwritten
< 0)) {
END_PROFILE(SMBwrite);
return(UNIXERROR(ERRDOS,ERRnoaccess));
}
If this code is commented out, like this
/*
if(((nwritten == 0) && (numtowrite != 0))||(nwritten
< 0)) {
END_PROFILE(SMBwrite);
return(UNIXERROR(ERRDOS,ERRnoaccess));
}
*/
If the file is saved, and samba is recompiled, the bug
completly dissapears!!
i was absoloutly amazed!
although this seems to work, i believe that the code i
commentd out was put in for a reason and so an
experenced programmer should alter this code so that
it does its job properly rather than just commenting
it out.
As i have only been using linux for 3 months, i can
only speculate as to what this is doing, but heres my
guess (correct me if i am wrong)...
An smb packet can contain about 100kb of data, files
less than this size can fit into one packet, so don't
need to be split up. Larger files need to be split up.
When samba receives the next packet of data, it checks
to see if the previous packet was saved into the file.
If not, some error has occured like drive full and
samba ditches the file and creates an error packet to
send back to the client.
For some reason samba is unable to correctly find the
ammount of data currently in the output file, maybe it
is a timing error where by the kernel is a bit slow
writing the data to the vfat partition. I don't realy
know, i am only guessing, but i would like to find out
what is actualy going on.
If this bodge of a fix worked for you, feel free to
email me, or post a follow up.
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Craig Shelley
2001-May-03 23:03 UTC
BUG FIX: SAMBA VFAT KERNEL 2.4.x & LARGE FILE SIZE > 90kb
I have had this crazy problem since i got 2.4.x
kernel.
I have a mounted VFAT partition with my mp3's on and i
wanted to share it with a windows computer. With
kernels 2.2.x, i had no problems reading and writing.
After upgrading kernel, i noticed that if i tried to
copy a file from the windows 95 machine to the linux
box, that was over about 100kb, i would get a access
denied error. I was baffled by this and posted aa
message onto this board, hoping that it would be
sorted out in the next version of samba.
I downloaded the latast releace of samba and kernel
2.4.4 and found the bug still existed. I have only
been learning c for about 2 weeks, and thought it
would be good learning experence to find this bug.
6 hours later, i found this...
In reply.c in the smbd dir of the source, there is a
function called reply_write
This is called when samba is requested to write a file
to a share.
using the method of placing loads of debug messages i
found that these commands check to make sure that the
data written to the file has actualy got there.
This is on line 2622 in the file smbd/reply.c
if(((nwritten == 0) && (numtowrite != 0))||(nwritten
< 0)) {
END_PROFILE(SMBwrite);
return(UNIXERROR(ERRDOS,ERRnoaccess));
}
If this code is commented out, like this
/*
if(((nwritten == 0) && (numtowrite != 0))||(nwritten
< 0)) {
END_PROFILE(SMBwrite);
return(UNIXERROR(ERRDOS,ERRnoaccess));
}
*/
If the file is saved, and samba is recompiled, the bug
completly dissapears!!
i was absoloutly amazed!
although this seems to work, i believe that the code i
commentd out was put in for a reason and so an
experenced programmer should alter this code so that
it does its job properly rather than just commenting
it out.
As i have only been using linux for 3 months, i can
only speculate as to what this is doing, but heres my
guess (correct me if i am wrong)...
An smb packet can contain about 100kb of data, files
less than this size can fit into one packet, so don't
need to be split up. Larger files need to be split up.
When samba receives the next packet of data, it checks
to see if the previous packet was saved into the file.
If not, some error has occured like drive full and
samba ditches the file and creates an error packet to
send back to the client.
For some reason samba is unable to correctly find the
ammount of data currently in the output file, maybe it
is a timing error where by the kernel is a bit slow
writing the data to the vfat partition. I don't realy
know, i am only guessing, but i would like to find out
what is actualy going on.
If this bodge of a fix worked for you, feel free to
email me, or post a follow up.
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/