[Samba] Fat32 - 1Gb file copy is failing

[Mattias Rönnblom]

Kandukuru_Suresh at emc.com writes:

> Hi All,
> Setup :- NAS device is running with 2.6.13 kernel and samba 3.0.32.I
> have connected a 4GB USB  flash drive having FAT32.USB drive is
> available from the windows machine as connected shared drive.
>
>>From my windows machine when I am trying to copy the file (>1Gb)   to
> shared USB drive(FAT32).it is giving error as shared USB drive is not
> reachable.
>
> File copy is working fine with small files.
> And I could copy the files more than 1Gb when the drive is with NTFS and
> other file systems
>
> I went though the code.
>
> In the following samba code piece:
> samba-3.0.32_old/source/modules/vfs_default.c:
>     714 static int vfswrap_ftruncate(vfs_handle_struct *handle,
> files_struct
> *fsp, int fd, SMB_OFF_T len)
>     715 {
> ...
>     734
>     735     result = sys_ftruncate(fd, len);
>     736     if (result == 0)
>     737         goto done;
>     738
>
> If comment out line 735/736 (not to extend space for the file to copy on
> fat),
> no error will occur during copying. (But we cannot do so otherwise all
> truncate
> requests from client would be skipped)
>
> Please advice  me what is the exact poblem,or it is known bug?. Any
> reply will be appreciated .
>

My understanding of what happens is that the smbd will issue a
ftruncate call to extend the size of the file (reflecting the wishes
of the Windows SMB client), which will result in those disk blocks
being preallocated and "zeroed out" by the Linux FAT driver. This
process can be very, very slow with big files and slow hardware and in
turn might cause the Windows SMB client to time out, since smbd cannot
provide a response in a timely manner.

What you can do is to modify the FAT driver is such a way that the
blocks are allocated in the File Allocation Table, but the actual file
contents is not set to zero (and thus will end up being semi-random).

That might well break whatever UNIX/POSIX semantics you have on
FAT. Not to mentioned any security issues, since old data (from
deleted files) will be available to user space apps which might not be
suppose to be reading it.

I've made such a hack in a lab environment, but it's a serious case of
programming-by-coincidence and does not work in more recent kernel
revisions. What I wanted to say was: it's certainly doable.

Best regards,
     Mattias