Tip when using Server Connect FileMove step, especially with a database

I recently worked quite a bit with FileMove in Server Connect.

I needed to move a file after save to another dynamic location, and the FileMove step only takes a few parameters, like
File Path, (where the file originates currently)
To Folder, (Where it is to go)

Take note at the wording, To Folder and take that very literally, and do not try pass the file name again, as it gets that from the File Path above.
You really only want to enter the new folder directory path you are sending the same file name to.

If you are allowing it to NOT overwrite duplicates and rather alter the file name if it finds a duplicate, and you are saving the image path and file name into a database field then you need to use the {{fileMove}} data binding as the value, because if it does rename a duplicate, it needs to write the new name to the database.

If you do need to alter the name, obviously you can but with the help of formatters, as there is only a single binding to work with, unlike some of the modules that give it split up into path, basename, extension, I used
{{fileMove.substr(7, fileMove.length())}}
because I am using a docker volume, and the path is different, in other words, server connect needs the full path of /public/my-media/image1.jpg which is the same path as setup in your Wappler Project Settings, User Uploads Folder.
On the HTML side however you need to strip out the /public part, which is the 7 characters used inside my substr formatter above.

If you like me, make the fatal mistake of not realising and accidentally adding the filename.extension into the To Folder field, you will land up with a mess like I did, and performing an ls -l on the folder you saved to will then have this

That d in front of the permissions, means directory, and my actual file was inside there, times that by 500 images and a few hours work, and you can imagine the self loathing for not fully testing.

The fix is actually pretty painless, just using the SSH built into Wappler.
First you need to know the name of your Volume

docker volume ls
Returns a list of all the volumes Wappler auto created when you entered the User Uplodas Path inside your Project Settings.
Look for the one ending in _user_uploads

Now you have the name of the volume, lets inspect it so we can get the path to the Mountpoint
docker volume inspect projectname__dockertargetname_user_uploads
Returns the information about the volume, we need the Mountpoint path which we will use in all our next steps.

Before we get to that, the normal commands you will find helpful, will be ls -l /your/path/ and cd /your/path/ which is literally just to list the files in a directory, and the change directory, simple as that.

To fix the problem I had created here are the commands which you may find useful if you do the same thing,

find /var/lib/docker/volumes/projectname__dockertargetname_user_uploads/_data/my-saved-images/ -type f -iname "*.jpg" -exec mv {} /var/lib/docker/volumes/projectname__dockertargetname_user_uploads/_data/my-saved-images \;

This finds all .jpg images starting inside the base folder which is currently full of directories, each with a single image inside, it ignores returning directories, only files, where the filename is anything ending in .jpg then moves the result of the find in a single go all back to the base directory.

I adjusted that and created a similar command to find all the directories inside the base directory and remove them all at once as well, so adjust as needed for your rm -r command, I am not listing it here, because when you get an rm -r command wrong then all your files are gone, so rather you do it at your own risk.
The find command though before the exec was

find /var/lib/docker/volumes/projectname__dockertargetname_user_uploads/_data/my-saved-images/ -type d

Once your find returns the correct results you can then append the -exec parts on knowing it will only remove what your find returned.

Some other useful docker specific commands are
df -h which shows all the space usage in each area
docker system prune which removes all the containers no longer in use, it leaves your volumes alone.

There is a larger post on this subject in the forum as well, hope this helps save someone hours.

Community Page
Last updated: