I would like to ask to get ftp support in sabnzbd. The reason is that there are major incompatibilities between Samba and protocol implementations in Windows and Mac. There are tweaks popping up - some working, some don't. Some are version specific and some use holes in the protocol stack. Either way - not good solutions in the long term.
The problem: A lot of NAS users only get to move/copy files that fit in 32 bit addressing. When unpacking/moving files these days, a lot of them are over 4GB in size and the transfer fails. A lot of the time badly, causing the file to disappear.
Solution: Instead of just using mounted file systems add support for other methods of transfers, like ftp. This will also fix the problem where some NAS drives aren't properly initialized upon restart.
tiwas wrote:
The problem: A lot of NAS users only get to move/copy files that fit in 32 bit addressing. When unpacking/moving files these days, a lot of them are over 4GB in size and the transfer fails. A lot of the time badly, causing the file to disappear.
Do you have examples of this? I don't recognize it. I only know of file systems that cannot handle files > 4.2GB, but/and you won't solve that with FTP as transfer.
Anyway: what you describe, can be realized in a post-processing script. So ... have you tried that?
With all the Samba NAS boxes I've tried with Windows I've had this problem regardless of the file system on the NAS. I'm able to transfer large files between the windows hosts, but as soon as I try to move it to a NAS location it just times out.
Are there any good primers on how to write post processing scripts?
A script will only do what you instruct it to do. So the first step for a FTP script is to do a manual FTP session that does what you want: move files and directories. So, can you start with that?
sabnzbd is running as a program (not service) on Windows 2008 R2 64 bit. I should be able to script a simple ftp session and then delete the file - but how do I check for status? If I get an error, deleting the file from the source would be...bad...