is it possible to check if a tracker’s window has been opened then closed in a sh script? I mean, one could ‘wait $!‘ but this will only look if the whole team is gone…perhaps adding -x options to your script to query all the matching dup:hash=** files and rmattr it from them? or just add the latter command to trackrunner, and remove that attr from your selected file(s)
Hmm, good point. How about a timed loop that will check for the the attribute and if count < 2 removes the attribute. the nice thing there is the query window will update live..
Then you could have an alert “Click here when done” that just cleans up everything. Not crazy about that though..
You could also grab the process ID and when it exits, do the cleanup.
Question- is it possible to make a query file from Terminal or a script? One that will open in Find like a saved query
1 Like
touch foo.query
addattr -t string _trk/qrystr "(name==*foo*)" foo.query
settype -t application/x-vnd.Be-query foo.query
open foo.query
1 Like
Thank you Lrrr!
I was missing the settype part..
1 Like
Ok, so now I have a working little app script. It uses fdupes (from HaikuDepot), plus Haiku’s built in commands to search for duplicate files, load them into a Query/Find window and it keeps everything clean. It can be used as a standalone app or ran under TrackRunner (with no need for the “use Terminal” option).
Just copy and paste into a text file and make it executable.
#!/bin/sh
# This script can be run from TrackRunner, Tracker or Terminal
# Check for fdupes
if [ ! -f /boot/system/bin/fdupes ]; then
BLERT=`alert "This app requires fdupes. Should I install it now?" "Nope" "Yep"`
if [ $BLERT = "Yep" ] ; then
notify "Installing fdupes "
yes | pkgman install fdupes
fi
fi
# Just to make sure fdupes got installed
if [ ! -f /boot/system/bin/fdupes ]; then
alert "There was a problem installing fdupes. Check you network connection and try again later" "Bummer"
fi
# work from tmp dir
# cd "$(dirname "$0")"
cd /boot/system/cache/tmp
# If no directory is specified, open dialog
SRCH="$@"
if [ -z "$SRCH" ] ; then
SRCH=`filepanel -k directory -l`
fi
notify "Searching for duplicate files.. This may take a while, hang tight"
# Run fdupes to find duplicate files
fdupes -rq "$SRCH" >> duplist
reindex -r dup "$SRCH"
sed -i '/^$/d' duplist
# add attributes to files found
while read F ; do
addattr -t string dup x "$F"
done <duplist
DEX=`lsindex |grep dup`
echo "Creating index $DEX"
clear
if [ -z "$DEX" ] ; then
mkindex -t string dup
fi
#Open custom query in Find
touch finddups
addattr -t string _trk/qrystr "(dup==**)" finddups
settype -t application/x-vnd.Be-query finddups
X=`cat duplist`
if [ -x $X ]; then
alert "No Duplicates Found"
else
open finddups
fi
# Wait for the Find window to close and cleanup
waitfor -e "w>finddups"
waitfor -e "w>/boot/system/cache/tmp/finddups"
while read F ; do
rmattr dup "$F"
done <duplist
rm duplist
rm finddups
Thanks for all the help guys!
EDIT: I fixed something I left out.. Should work for everybody, but if not, please let me know!
3 Likes
Works well! Thanks, @shaka444
Sorry to butt in so late, but here’s a Ruby version for comparative purposes: Misc Haiku utilities and ports - Browse /dedupfiles at SourceForge.net
You could try using the waitfor command here since you will know the exact name of the find window. You can avoid the looping/sleeping by using something like …
waitfor -e 'w>/boot/system/cache/tmp/finddups'
Edit: I guess that won’t work like I thought without some extra commands. The title depends on whether you have Tracker set to display the full path in the title bar.
Thanks Lrrr
Yes I was trying to find a way to avoid the loop/sleep. Its been a little tricky but I’ll keep playing with it..
Sounds like a new filesystem would be the better aproach 
There is no way to know if the shasum is correct for the file state apart from guessing the timestamps look “similar enough”
This would not detect intrusions, after all, just write a new sum. If you can write the file contents you can write a new sum.
But no, BFS is not really suited to this, there are however filesystems that supports this natively, btrfs and zfs for example store a checksum for each block they write, which is even more fine grained than “something in the file changed” 
Lrrr,
waitfor -e “w>finddups” worked! I’ll change the code above and the link.
Thanks!
I think the BFS driver could be changed, so that it would change the checksum if the file content is changed and checked the file against the checksum wile reading. This could of course not detect Inrusions, but it would detect bitrot and read/write errors. BTRFS and ZFS do this internally on the block layer.
This was what I was thinking, yeah.
If you timestamped the checksum changes, that would do the same thing tripwire does (did?) for detecting changes?
It’s not intrusion detection on its own, but it would detect modified files which can be a helpful piece of intrusion detection.
The problem is that the window title changes depending on whether the Tracker option to display the full path in the title bar is enabled. So, in theory you could call the waitfor command twice, with both titles, since the waitfor command will exit immediately if it didn’t find the thread it was supposed to watch.
waitfor -e 'w>finddups'
waitfor -e 'w>/boot/system/cache/tmp/finddups'
1 Like
You’re right. I added the extra line.
Thanks Lrrr
Checksumming a whole file on each read is way too expensive, and we can’t really add block based checksums without changing the on-disk structure
1 Like
On each read would be insane.
Checksumming with a background process on file close if a write has taken place shouldn’t be particularly onerous, though; you would have to keep some kind of disk-persistent list of open files so you could resume checksumming after an unexpected reboot, similar to various filesystem’s journals.
It wouldn’t be much work to set up, but the benefit would be 100% in an area that Haiku (understandably and for good reason) largely doesn’t engage with, though.