rfm - RepRapFirmware FileManager [duetbackup successor]



  • @wilriker thanks for the quick fix.

    Regarding config file for connection parameter:
    For users having multiple duet-based printers it would be cool to to store all these connections settings domain, port and password in a kind of connection group.
    e.g.

    [printer1]
    domain=<printer1-ip>
    port=<printer1-port>
    password=<printer1-pw>
    
    [printer2]
    ....
    

    Usage then could be rfm -device printer1 <cmd>

    I did something similar in a python-based backup script for my daily backups and found this very useful.

    What's your opinion about this?



  • @mloidl I like that and will implement something like this. But even though I listed it first it's currently last in priority. 😉


  • administrators

    @wilriker My vote goes for RepRapFirmware Total File Manager



  • @t3p3tony said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    @wilriker My vote goes for RepRapFirmware Total File Manager

    Yeah, that's what I thought of, too. 😂

    Also another good idea might be
    "[File-]Resource Manager for RepRapFirmware-based Filesystems" -> rm-rf 🤣
    (Windows user's probably won't get this one)



  • You are evil! I wonder if anyone would even dare to use the tool in Linux then.



  • @wilriker said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    @t3p3tony said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    @wilriker My vote goes for RepRapFirmware Total File Manager

    Yeah, that's what I thought of, too. 😂

    Also another good idea might be
    "[File-]Resource Manager for RepRapFirmware-based Filesystems" -> rm-rf 🤣
    (Windows user's probably won't get this one)

    I "googled" that and came up with "force deletion of everything in the root directory". That's the equivalent of a "nuke" button isn't it?



  • @obeliks said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    You are evil! I wonder if anyone would even dare to use the tool in Linux then.

    I was trying hard to find any reason to also add a / at the end to make it even more evil. 😂 And top class would be to get sudo prepended. sudo-rm-rf/. Perfect name for any tool on Linux. 🤣



  • @deckingman said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    I "googled" that and came up with "force deletion of everything in the root directory". That's the equivalent of a "nuke" button isn't it?

    More or less. There are some protections in place but if you run

    rm -rf / [note the spaces]
    

    either as root user (admin user with full privileges in Linux) or prepend it with sudo (which will provide a regular user with root-rights) it will do exactly that. It will erase all contents of your hard-drive and depending on the configuration also of all mounted external drives. Not as fast as a giant hammer but fast enough to have made probably unrecoverable damage until you notice.



  • @wilriker said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    @obeliks said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    You are evil! I wonder if anyone would even dare to use the tool in Linux then.

    I was trying hard to find any reason to also add a / at the end to make it even more evil. 😂 And top class would be to get sudo prepended. sudo-rm-rf/. Perfect name for any tool on Linux. 🤣

    That is a lot of nonoes in one sentence 🙂



  • Back to business:

    Release v1.0.0-RC2

    I have just release v1.0.0-RC2.

    Changes

    Help

    This second release candidate has help texts for every sub-command now that are accessible via

    rfm help <command>
    

    Command Structure

    The second major change is the structure of the parameters and options. This now resembles better the style of common CLI tools. Please see the appropriate help pages to see the format.

    rfm backup Changes

    Most notably also the format for rfm backup changed. This now is

    rfm backup <common-options> [-removeLocal] [-exclude <excludepattern>]* [<local/path> [<remote/path>]]
    

    where -outDir has been reduced to <local/path> with a default of the current directory if omitted and -dirToBackup is shortened to <remote/path>. The default is still 0:/sys. In case this needs to be changed the local directory also has to be provided.

    rfm ls

    rfm ls now accepts multiple remote paths to list.

    Fixes

    • panic when no sub-command is provided is replaced with default help text
    • Uploading single files was broken


  • Release v1.0.0

    And here comes the first official release v1.0.0.

    Release Notes

    This release implements all functions listed in README.md, i.e. it can

    • download files
    • upload files and folder
    • backup (like duetbackup did before but slightly different and simplified syntax)
    • list directory contents
    • move or rename files and directories
    • create directories
    • delete files and directories

    This covers all functions of the HTTP interface.

    Also it is capable of handling multiple devices via an automatically managed configuration file.

    As usual there are releases for Linux x86_64, Windows x86_64, MacOS X x86_64, Linux ARM and Linux ARM64.



  • @wilriker
    Thank you very much for the release. Well done. I'll test it today when i'm at home.
    Especially i like the way you implemented the multi-device handling.



  • @mloidl Thanks! 🙂

    Re device handling: I tried to make it as automagically as possible for the user and hope it will be useful like that.

    But as always: all feedback is welcome. 🙂



  • @wilriker Tested 1.0.0 and everything worked perfect.
    But i have one question. Is there any reason for not creating the rmf.toml as hidden file?



  • @mloidl said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    But i have one question. Is there any reason for not creating the rmf.toml as hidden file?

    None in particular. At least none other than symmetry. On Linux and MacOS it's simple by just prefixing the filename with a dot. But on Windows I would have to access file system attributes to achieve that. So I dropped this idea (that I also had in the beginning). Of course I could change the name to .rfm.toml and on Windows it would just have this name without being hidden.

    EDIT: I just researched how to create hidden files with Go on Windows and stumbled across an open bug that says opening hidden files on Windows for write access fails with an error. So even if I got it somehow hidden I could never edit it after that anymore.

    EDIT2: The above bug does not apply since I write the new settings to a temporary file and only if that was successful I overwrite the existing one with the new one so that in case writing the file fails I do not jeopardize the current settings. Still I rather don't want to go to the length of hiding the file on Windows specifically.



  • I have just tried this, and getting "Unable to save configuration to rfm.toml. The process cannot access the file because it is being used by another process."

    This is on Windows 10, 64bit.

    Just a suggestion, why not store the file in the same directory as the rfm file? Since it is a self-contained executable, I keep it in a folder, with the backup folders as sub-folders of the main folder. The idea is that I keep regular backups of this whole folder (with the rfm executable), and simply know that everything is there.

    Currently I have plain text files with the commands I run (for my machines), to simply copy/paste, inside of this main folder.



  • @jacotheron said in rfm - RepRapFirmware FileManager [duetbackup successor]:

    I have just tried this, and getting "Unable to save configuration to rfm.toml. The process cannot access the file because it is being used by another process."

    That's not how it is supposed to be. I'll have to check if I forgot to release the file at some place. It should definitely not block itself.

    Just a suggestion, why not store the file in the same directory as the rfm file? Since it is a self-contained executable, I keep it in a folder, with the backup folders as sub-folders of the main folder. The idea is that I keep regular backups of this whole folder (with the rfm executable), and simply know that everything is there.

    The reason for that is that the executable might be in a directory where the user does not have write permissions, e.g. if I install it in Linux to /usr/local/bin/rfm (actually I do) so that it is accessible by every user of the system. The same goes for C:\Windows\* or C:\Program Files\*. If anyone wants to do that they should be able to. The only place where the user always has write permissions is the user's home directory.



  • @jacotheron I found something that might be the reason for the error message you are seeing. I uploaded a possible fix to my Dropbox. Can you please test if this issue still occurs in that version?



  • I have just tested the new version, and it worked - no issues found. The devices file was made and saved.



  • @jacotheron Thanks for confirming. I will do an official bug fix release tomorrow.


Log in to reply