I just purchased, installed and activated Trickster.
I don’t see any files in the “All files” list; only applications.
Steps taken:
Double click on a PDF file in Finder (file is located in the Downloads folder) –> the Preview application starts and loads the file.
Close the Preview application.
Click on the Trickster icon in the menu bar –> “All files” list shows the Preview application at the very top, but not the file.
The Downloads folder is in the list of “Watched Folders”.
“Whitelisted Text” is empty.
“Excluded Extensions” is empty.
“Excluded Paths” is empty.
“Excluded Text” has the two default entries: “.dropbox” and “.Trash”.
If I drag and drop the PDF file onto the “DROP A FILE TO TEST” box, I get “The file will appear in Trickster. Not excluded by any rule”.
Using macOS Monterey 12.6.4. Trickster is in the Utilities folder.
I’ve given Trickster “Full Disk Access” in Security & Privacy –> Privacy (i.e. added to the list, ticked).
The user home directory is on a secondary volume.
If I add a folder from the main volume to the “Watched Folders” list and I copy the PDF there (and open it from this location), it is shown in the “All files” list.
Thank you for buying Trickster. Let’s get to the bottom of it.
It sounds like the problem may be related to the your home folder being on a secondary volume.
Is this secondary volume on an external device? If yes, how is it connected to your Mac?
Full Disk Access provides no benefit to Trickster. It’s not what most people think, meaning that it doesn’t go around regular sandboxing.
The home folder is on a volume in the same APFS container as the main/default macOS volume (on the internal SSD). There are several users on this Mac, and all have their respective home folders on the secondary volume. The main/default macOS volume does not have any user data (only operating system and applications). I created a temporary folder on the main/default macOS volume for testing, and it appears to be tracked correctly.
I’ve been performing some more tests, and it seems Trickster does track newly created files correctly. However, it does not track access to most of the existing files. Some existing files are tracked, but most are not. I only tested PDF, TIFF, and JPG thus far (all opened in Preview). I couldn’t identify a pattern – i.e. differences between files that are tracked correctly vs. those that are not.
Could you go that file that doesn’t show in Trickster in Finder and check its Date Last Opened column? Add the column to show in Finder if it doesn’t already appear. Right click on the column headers to show the list of available columns to add/remove.
See if that date is what you expect and if it updates when you open the file? Should look like this:
Performing some more experiments, I discovered that the “Last Opened” info shown in Finder (and in “File Info”) is not the same as the Unix atime. I can update atime using “touch -a”, but this has no effect on the “Last Opened” info shown by Finder.
As mentioned, the “Last Opened” info is not updated for some of my files when manually opening them. Whereas I can update the atime for all files using “touch -a”. Of course, this doesn’t help Trickster, but I thought it may help diagnose the issue.
I have also inspected file metadata attributes using “mdls”. For files not tracked by Trickster (also lacking “Last Opened” info, even after manually opening them), there are no metadata attributes.
Invoking “touch -m” on these files creates metadata attributes. Interestingly, “touch -a” does not create metadata attributes.
Anyway, after using “touch -m”, the files start behaving – both in terms of “Last Opened” and, also, in Trickster.
Good to see a power user here. Yeah, looking at your info panels it looks like there’s no Spotlight metadata on your user drives there. Can you find any of the non-working files on your user drive using Spotlight at all? Could it be that these drives are added to the Spotlight Privacy list (Check Spotlight Settings / Privacy)? Oner suggestion on the internet is to add the drive to the privacy list and then remove it, to restart its indexing. You could try that too. It’s #7 on this list: Spotlight Search Not Working on Mac? Try These 9 Fixes
The Downloads folder (where the documents used for testing reside) is not excluded from Spotlight indexing. However, performing Spotlight searches for ‘offending’ documents does appear to not find the documents – at least some of them (I haven’t performed exhaustive tests).
Attempting to reindex the Downloads folder (by adding it to the exclusion list, and then removing it) does not seem to make a difference in terms of Spotlight results when searching for ‘offending’ documents. For what it’s worth, I did wait for the mdworker processes to finish.
On a personal note, I’ve given up on Spotlight search a long time ago.
Is the presence of files in the Spotlight index a requirement for Trickster?
Trickster uses two different ways to track the changes. The one that’s used for Opens is done using Spotlight. The one for new or modified files is not using Spotlight. Maybe you need to add and remove the whole partition with users so that Spotlight sees it. That’s what one of the articles there suggested. Maybe there’s another reason that your downloads folder is not getting the metadata but I don’t know what it might be. I’ve never had a setup like that on Mac, with user data on a separate partition.
Regarding Spotlight, some of the files in the Downloads folder (which is what I’ve been using for testing) are present in Spotlight, some are not. There’s no rhyme or reason that I can spot (no pun intended;-).
I don’t think having the user home directory on a separate volume has anything to do with any of these issues (whether Spotlight or Trickster).
While I’m (obviously) disappointed that Trickster doesn’t work with some of my files, I am willing to accept that the problem lies outside of Trickster.
It would be nice if the “DROP A FILE TO TEST” box would reflect the true tracking state for the dropped file (ideally with some helpful explanation/reason). This would enable users to diagnose issues similar to the ones I’ve been experiencing, without having to revert to forums or technical support. In an ideal world, Trickster should also offer a way of correcting the situation (if possible). While employing this procedure would be rather tedious for the end-user (as it’s file by file), it would be better than nothing…
That’s a good suggestion regarding the “drop to test”. I haven’t encountered this problem with customers often, and I’ll need to check how to test it programmatically. It’s strange that touch -m would add Spotlight attributes but -a no. They just change different kind of unix time attributes, allegedly.
In any case, that’s not a way to treat the solution for customers, even if Trickster detects that the problem is missing Spotlight attributes. I’m going a little through docs of all the different Spotlight-related command line tools. Quite a bit there between mdutil, mdfind and mdls. Gonna see which type may be more useful for understanding these kind of issues.
I had a PDF that would not get indexed by Spotlight no matter what I tried (that includes repeated attempts to re-index the parent folder, as well as touch with various arguments). No file metadata, either.
However, after effecting a minor change to the PDF and saving it, it appeared in Spotlight, got metadata, and was properly tracked by Trickster.
@Radu Thank you for this information. This reminds me of something from my previous research. It is possible that these files that don’t work are files that were downloaded from the Internet with Safari (and maybe other files). Such files would usually get a quarantine extended attribute and thus won’t be exactly like others and they may have problem indexing until opened and/or saved or moved or something like that, at which point the quarantine flag will disappear. I didn’t see it happen lately but maybe it’s related to what you have.
Try the following command in your Downloads folder and see if there’s a connection between the com.apple.quarantine extended attribute and the files that exhibit this problem: ls -ld@ * or ls -ld@ ~/Downloads/*
I ran the following over a collection of 100+ files:
for f in *; do echo; echo; echo $f; mdls "$f"; echo; xattr -l "$f"; done
I also opened all these files (no editing) and checked whether they were tracked by Trickster. 17 of these files were not tracked by Trickster. The only thing these files have in common is the fact that mdls doesn’t return any information. Needless to say, these files are also not indexed in Spotlight.
Equally, all the other files (that are tracked by Trickster) do have file metadata attributes – i.e. mdls returns information for them.
I believe this conclusively connects the two together – i.e. Trickster and mdls. There was nothing in common across the extended attributes (i.e. in the xattr output).
So, I think you can safely use mdls to improve the “DROP A FILE TO TEST” box.
I don’t know whether there is a way of generating the file metadata attributes programatically.
After some more testing, I found touch -m to not be all that reliable. For some files it resulted in file metadata attributes being created, for others it didn’t. The only thing that consistently resulted in file metadata attributes being created/initialised was to effect changes to the content of the file (i.e. edit and save).
