I investigated about copying a file which exceeds the disk size from WindowsXP to Samba3.2.6. It causes "NT_STATUS_DISK_FULL" error but its response take more time than Windows Server.
Because ftruncate is executed in that sequence.
I compared the behaviour of "NT_STATUS_DISK_FULL" between Samba and Windows 2003 Server by wireshark.
As a result, I found that SMB_TRANS2(SMB_SET_FILE_END_OF_FILE_INFO) should return "NT_STATUS_DISK_FULL" error.
So, I think vfs_set_filelen() should return a error before doing ftruncate when "strict allocate" is "yes".
I made a patch for samba 3.2.6.
BTW, the ftruncate of Solaris10's ZFS seems to need more time than Ext3 of Linux.
So, if you try to check this issue on Linux, you might think there is no problem.
Created attachment 3826 [details]
a patch for samba 3.2.6
Created attachment 3828 [details]
I think this patch (almost the same as yours) is a better fit. Firstly, it moves the code to within strict_allocate_ftruncate() which copes with all the other logic needed when strict allocate is set, and secondly the size to compare from the dfree return needs to be space_to_write, which is the difference between the current length of the file and the new ftruncate extended length, not len, which is the new ftruncated length. If we compare against len then we're expecting the full size of the file to be available even if we're extending only by one byte.
Can you check this and confirm it fixes the problem ? If so I'll commit to all branches.
Thanks a *lot* - great catch of a problem in the code.
I confirmed your patch on CentOS5(Ext3) and Solaris10(ZFS).
There is no problem.
Thanks for your work.
Applied to all branches, thanks !