fvdw as an FTP client, is that possible?

[Cubytus]

Hi there,

during the process of shutting down my seedbox, I'd like to repatriate the files on the fvdw-equipped LaCie cloudbox.

Currently, I use the computer to mount fvdw first as a network share, then connect the computer to the seedbox, and transfer the files from the seedbox to fvdw. These are usually lengthy transfers amounting in the hundreds of gigs.

It doesn't sound very practical and is prone to unexpected disconnects whenever the Cloudbox strains under the load, and forces me to keep the computer running.

Would there be a way to make the fvdw firmware remember pre-defined FTP connections and queue transfers?

[Jocko]

Hi Cubytox,

I do not use a seedbox but according with your question, you have a ftp access on your remote box.

So what you want to do is to backup (or sync ?) the seedbox content to the NAS. (=> get commands and not put commands)

In this case, you can use wget to retrieve the seedbox content. I advice you to use a shell script and it should have at least this commandline

Code: Select all

chdir '/share/path-to/your-download-location' &&/usr/bin/wget -xpcba 'yourlog.txt' --ftp-user='yourlogin' --ftp-password='yourpwd' -r -np -l 7 -R '*.ext' -nv ftp://your-ftp-seedbox-url/pathto/folder

useful wget options:
-b Go to background immediately after startup
-a logfile
-c Continue getting a partially-downloaded file. This is useful when you want to finish up a download started by a previous instance
-x create a hierarchy of directories when retrieving recursively
-p not really useful on a ftp site (get all images, etc. needed to display HTML page)
-r specify recursive download
-np don't ascend to the parent directory (=> jail wget in the folder set in the url)
-l maximum recursion depth (=> optional option, in my example descend up to the 7th subfolder)
-R comma-separated list of rejected extension
-nv turn off verboseness, without being quiet

Additional options:
-P 'backup_'`date +%F_%H-%M-%S` (if you want to have a timestamped backup)
-X list of excluded directories
-U -fake-ua identify as fake-ua instead of Wget/VERSION (if seedbox black list wget user agent)

Warning: keep in your command-line chdir .... && to be sure to run only wget if the new current directory is rightly set (to avoid to backup to a bad location!)

Wget is not a sync tool if you want only to sync nas with the seedbox, you need a tool curlftpfs to be able to mount your seedbox on a local folder and then use rsync

[Cubytus]

To be fair, I rarely need to download the full seedbox content, only a mix of files and folders. Granted, I could organize the seedbox content a bit differently and put in one folder all I intend to download later on, mimicking the folder hierarchy on fvdw.

I tend to prefer rsync since it can easily resume a broken download and avoid frustration on a multi-hour download when the connection breaks. I do use it on the LAN between the Cloudbox and the Synology, since both NFS and AFP servers on the Cloudbox tend to freeze and crash under sustained usage (300GiB+). I'd rather have the transfers resume automatically, though.

Instead of relying on the user's skill to write a decent script, have you thought about adding an assistant in the web GUI that would just create the correct command line from a set of fields? Your suggestion to use curlftps looks even better, as it would allow mounting the seedbox as a local folder, just as I do on the Synology.

What I found missing in fvdw firmware is the "screen" utility that would allow backgrounding a long-running task and quit the Terminal on the host computer.

[Jocko]

Hi Cubytus,

We go to examine if we can implement curlftps.

What I found missing in fvdw firmware is the "screen" utility that would allow backgrounding a long-running task and quit the Terminal on the host computer.

you already can do it without screen command !
Just open another terminal and run these two kill command on the wanted process : find the process id (using ps) and run

Code: Select all

kill -20 PID
kill -18 PID

kill -20 will suspend the process and kill -18 will resume the process, in background. So now, closing both your terminals won't stop your process. :)

Instead of relying on the user's skill to write a decent script, have you thought about adding an assistant in the web GUI that would just create the correct command line from a set of fields?

Is it not already the case with the wget menu :scratch