[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 19/09/18 14:54, Dom Rodriguez wrote: > I would approach this problem with the `find` command. > > You want all the JSON files to be removed, so I would run this command > *in* the folder - do not run it outside of this folder, as it will > clear all files that have the .json extension. > > The command I propose is: > > `find ./ -type f -iname '*.json' -print -delete` > > This will recursively find all files that have the .json extension, > and delete them, whilst *also* printing each file to the console. You > can omit `-print` if you do not want that to happen. > > The `-iname` part matches all .json files that might have capital > letters in them as well, but if they don't, you can just use `-name` > instead :-) > > (Disclaimer: running this command is at your *own risk*, and I do not > take liability for any unintentional data loss because of it. I > recommend making a backup of the photo folder first.) > > I'm interested though, are these photos from just a camera? Never > really seen photos accompanied with a JSON file as well. Might be > metadata.. though... DANGER WILL ROBINSON! Dom is nearly spot on and at least warned you about potential data loss... which is very wise. I seriously doubt you want to waste the time and effort making an entire 1 for 1 backup of a gigantic picture folder first though so let's add some sensible safety precautions. Manipulating vast amounts of files from the shell is bread and butter for a sysadmin but a fat fingered or ill-conceived find command is a great way to ruin either your data or your bosses data if you're not careful (ask me how I know haha). Do NOT move to the correct folder and issue your commands: a typo here will ruin you. Pass the full correct path to dangerous commands ALWAYS. Do NOT skip this. One day you will forget to CD to the correct directory first, or accidentally copy/paste into the wrong SSH window, etc. Full path always. # set up your working directories as variables export TARGETDIR=/home/richard/pictures/blah/blah export TMPWORKDIR=/home/richard/TMPWORK export TMPDUMPDIR=$TMPWORKDIR/TMPDUMP # make tmp directories and cd into place mkdir -p $TMPDUMPDIR && cd $TMPWORKDIR # grab a clumsy but complete recursive file listing beforehand ls -alhR $TMPWORKDIR | tee -a files.before # run a test on $MYDIR first! # gives you a hit.list of one entry per line with full path to file(s) find $TMPWORKDIR -type f -iname \*.json -print0 | \ xargs -0 | tee -a hit.list # get a count of how many "hits" you have wc -l hit.list # results look ok? then MOVE don't DELETE target file(s) to $TMPDUMPDIR # some extra safeties enabled to avoid overwrites, empty strings, etc find $TMPWORKDIR -type f -iname \*.json -print0 | \ xargs -0r mv --verbose --backup=numbered -t $TMPDUMPDIR # grab another file listing afterwards for diff purposes ls -alhR $TMPWORKDIR | tee -a files.after # check the count of actually moved files matches up ok ls $TMPDUMPDIR | wc -l And you're (probably) done. There are still things that can go wrong with this, even when you're being super careful so be warned. Unexpected globs, permission errors when moving files, borked characters or unexpected weirdness in file names/paths can all seriously ruin your day. You're 'only' wiping a bunch of unwanted json metadata files but these guidelines apply to any programmatic deletion or move of filesystem contents - countless data has been destroyed in moments by inattentive users and sysadmins. Be very, very careful! You'll end up with your cleaned file tree looking as you wanted - hopefully. If you really screwed something up badly, at least you've got complete before and after recursive directory listings (files.before and files.after), a list of the files you operated on (hit.list) and most importantly all the moved files themselves (in $TMPDUMPDIR) because you were smart enough to keep them instead of wiping them with rm: don't ever, ever do that. Shell scripting the reversed operation in case of disaster will be more challenging, but at least you'll have the option eh? I'd personally save myself a huge amount of worry whilst avoiding costly and time-consuming backups with a simple ZFS snapshot but that's probably not an option for most people. It should be because non-CoW filesystems are all crap and shouldn't be used anymore by people who value their time, data and sanity but that's a discussion for another day. Hope that all makes sense and the example commands can be adapted easily if you want to try them. And did I mention you should be REALLY careful? :] Cheers -- The Mailing List for the Devon & Cornwall LUG https://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq