Problems with bulk renaming command

Reasons for not using gui

  • you cant script it… no record of what you did
  • you may wish to do it in a shellscript
  • you may prefer typing to mouse clik
  • your gui may not have Krename… that is kde
  • your gui may have limited capability… commands are usually more flexible
  • you may actually enjoy some mental gymnastics
2 Likes

All the things he said :smiley:

That MMV looks interesting - kinda wish I’d known about it maybe 10-15 years ago… but Perl CPAN rename / prename does everything I need… I don’t need to learn a new syntax, as it works with sed style regex - which is obtuse and obfuscating, and I’ve barely scratched the surface of it in 30 years… I can easily do recursive by using find and exec…

2 Likes

Hi @artytux,

A well written open source gui for doing rsync is FreeFileSync. I use it all the time to backup (sync) my personal files to an external disk.

2 Likes

@easyt50

Had not known about FreeFileSync always good to have option of other gui for rsync
just in case Backintime stops being maintained or just stops working properly.
Mentioned previously Backintime does have one major bug (concerns links in and to folders)

appreciate the info
Thank You

Just happened to spot this again… for rsync’ing, I highly recommend lsyncd. Simple reason: it provides completely-automated, immediate-update coupling between a local and remote filesystem tree. (Similar to how a Dropbox folder syncs when their daemon running, except lsyncd isn’t really intended for incoming sync, only outgoing.) It will auto-sync all local file changes (or just creations but not deletions, if you configure it that way), you just write a config file and start it running. I have it configured to start shortly after login, for the local directory tree I keep synced to my file server. I save or delete anything locally in that tree, and within a second or two the changes are already replicated to the other machine.

The config format is (here again) somewhat byzantine, but that’s mostly just because of how flexible/powerful it is. For the most part, you can just ignore all the features you’ll never need.

(I will save anyone who decides to try it out some frustration and hair-pulling, though, with this tip: If you’re going to have it monitor a large directory tree, you’ll probably need to increase your system’s inotify limit because it will need a ton of them. I eventually figured out that was the culprit behind some issues I hit early on, which were easily solved by creating an /etc/sysctl.d/lsyncd.conf file containing:

# lsyncd requires a lot of inotify watches for large trees
fs.inotify.max_user_watches = 131070

(The initial value is the very arbitrary-seeming 14790, so I’ve increased it by nearly a factor of 10. That’s because lsyncd will need one watch per directory monitored ­— not per file, thankfully — and the tree I’m syncing is… well…)

$ find -type d -print|wc -l
20235
$ find -type f -print|wc -l
713207

…Really? Are you saying you know people who’d be impressed by this stuff? Because, I’ve never met any.

1 Like