rfm - RepRapFirmware FileManager [duetbackup successor]

Jacotheron

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.

wilriker

@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.

wilriker

@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?

Jacotheron

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

wilriker

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

wilriker

Release v1.0.1

Bug fix release to fix the issue where on Windows rfm.toml would not be overwritten. Get it at GitHub Releases page.

gtj0

Hey Manuel, rfm has been working great for me but is there any chance you could automatically exclude the "System Volume Information" directory or maybe save excludes in the rfm.toml file?

wilriker

@gtj0 I'll think about something.

Meanwhile you can also use rfm to just delete this stupid folder. It doesn't serve any purpose in the first place. I don't think that removable media are supposed to even have this folder.

wilriker

@gtj0 Here you go

Release v1.1.0-RC1

Get it at the GitHub Releases page.

This release implements the persisting of -exclude parameter values in rfm.toml. These parameters will be persisted separately for backup and upload command so they do not confuse each other.

A new keyword reset has been added as a recognized value for the -exclude parameter to delete all persisted excludes for the current command, i.e.

rfm backup -exclude reset ...

will remove all persisted excludes for the backup command. Further -exclude parameter after that (even in the same command) will add new excludes.

Note that order is relevant, i.e.

rfm backup -exclude 0:/gcodes -exclude reset backup-dir 0:/

will backup everything in 0:/ since the given exclude for 0:/gcodes was reset by the following -exclude reset parameter.

gtj0

Is -removeLocal working?

./rfm backup -domain duet0 -removeLocal /tmp/duet0 /
...
Removing no longer existing files in /tmp/duet0/gcodes

But it doesn't actually remove any files from the local filesystem.

wilriker

@gtj0 Last time I checked it worked. It will only remove local files that do not exist anymore on remote (like -delete for rsync). I will check tomorrow if something is broken with it.

wilriker

@gtj0 You were right, -removeLocal was broken for removed files (it worked for removed directories). So here is

Release v1.1.0-RC2

This fixes broken -removeLocal parameter of the backup sub-command that did not delete files locally.

Get it at the GitHub Releases page.

3mm

Hi wilriker,

I hate to sound stupid, but how do I use it? Where do I put the files? And how do I access it? My system is Windaze 7 PC and a DUET-EtherNet controller.

Thanks in advance...3mm

gtj0

@wilriker

Yep, -removeLocal now works.
You can't specify the remote directory as 0:/ any more though. Not sure if this is intentional or not.

$ ./rfm backup -domain duet0 /tmp/duet0 0:/
2019/07/30 05:49:53 Fetching filelist for 0:/0:
2019/07/30 05:49:53 Directory not found

Doesn't matter to me, not sure if it's matter to others.

wilriker

@3mm You download the release for your operating system. For Windows that would be rfm-windows_amd64.zip. Then you unpack that to a location of your choice. It is a command-line tool so you have to open cmd and navigate to the directory where you unpacked rfm to (alternatively: in Explorer right click while holding shift in the directory where rfm.exe is located - this should provide a context-menu entry to open a command line in this directory).

There you can simply run

rfm help

to get an overview and the available sub-commands. With

rfm help <subcommand>

you can see individual parameters of each sub-command.

wilriker

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

@wilriker

Yep, -removeLocal now works.
You can't specify the remote directory as 0:/ any more though. Not sure if this is intentional or not.
$ ./rfm backup -domain duet0 /tmp/duet0 0:/
2019/07/30 05:49:53 Fetching filelist for 0:/0:
2019/07/30 05:49:53 Directory not found
Doesn't matter to me, not sure if it's matter to others.

No, that's a bug. I'll look into that.

wilriker

@gtj0 Found it and fixed it.

Release v1.1.0-RC3

This can be found as usual on GitHub Releases page.

Another bug fix. There was a regression introduced in v1.1.0-RC1 where it was no longer possible to specify the root directory of the SD card as 0:/. This is fixed in this release.

Also this release candidate is intended to be the last one before final release of this version.

3mm

@wilriker

Thank you very much!

3mm

wilriker

Arch User Repository Package

For Arch Linux users: I have submitted a package to install rfm via AUR: https://aur.archlinux.org/packages/rfm/

This is available for x86_64, arm, armv6h, armv7h and aarch64.

wilriker

Release v1.1.0

v1.1.0 has existed Release Candidate stage and is now available at GitHub Releases page or via Arch User Repository.

Reiterating the changes:
This release implements the persisting of -exclude parameter values in rfm.toml. These parameters will be persisted separately for backup and upload command so they do not confuse each other.

A new keyword reset has been added as a recognized value for the -exclude parameter to delete all persisted excludes for the current command, i.e.

rfm backup -exclude reset ...

will remove all persisted excludes for the backup command. Further -exclude parameter after that (even in the same command) will add new excludes.

Note that order is relevant, i.e.

rfm backup -exclude 0:/gcodes -exclude reset backup-dir 0:/

will backup everything in 0:/ since the given exclude for 0:/gcodes was reset by the following -exclude reset parameter.

Bug Fixes

-removeLocal was broken for files (working for directories though)
Sub-command upload would fail most of the times (this was fixed between RC3 and this version)