sveinbjornt / searchfs Goto Github PK

Please support the standard DESTDIR variable in your Makefile.

If I run

sudo make install DESTDIR=/tmp/root

then I would expect the files to get installed in

/tmp/root/usr/local/bin/searchfs
/tmp/root/usr/local/share/man/man1/searchfs.1

Note that your existing Makefile variable DEST_DIR, which serves an unrelated purpose, then becomes confusing. You may wish to rename that variable.

On macOS 10.14.4 with Xcode 10.2.1, I git pulled to update my clone, and did make. I saw the following warnings that I don't remember seeing before:

version-min=10.7 main.m
main.m:419:24: warning: 'fsgetpath' is only available on macOS 10.13 or newer
      [-Wunguarded-availability-new]
        ssize_t size = fsgetpath(buf, buflen, fsid, obj_id);
                       ^~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/fsgetpath.h:46:9: note:
      'fsgetpath' has been marked as being introduced in macOS 10.13 here, but
      the deployment target is macOS 10.7.0
ssize_t fsgetpath(char *, size_t, fsid_t *, uint64_t) __OSX_AVAILABLE(10...
        ^
main.m:419:24: note: enclose 'fsgetpath' in an @available check to silence this
      warning
        ssize_t size = fsgetpath(buf, buflen, fsid, obj_id);
                       ^~~~~~~~~
1 warning generated.
strip -x searchfs

The build succeeded despite the warnings.

This is not really a "issue", and I realise that it's not even a feature request, but I still wanted to discuss the possibilities.

Is it possible to add support for other file systems?

Are there any other file systems which have Catalog of files? I guess NTFS does. (as Everything uses it for search)

But do you know if ext3/4 or any other linux file systems have this?

(snip)
/Applications/iTunes.app/Contents/MacOS/iTunesHelper.app
Unable to get path for object ID: 3430632Unable to get path for object ID: 3460180/Applications/Video/Adapter.app
/Applications/Video/MediaInfo.app
(snip)

This happens multiple times in the results, for different object IDs.

Let me know if/how I can provide more logging or diagnostics.

The Makefile is hardcoded to install into /usr/local. Please provide a Makefile variable (perhaps PREFIX) that a user could specify at the command line to install to a different location.

Catalina 10.15.3

searchfs seems unable to search the r/w mountpoint where all user data is stored. Tried v0.3 from https://sveinbjorn.org/files/software/searchfs.zip as well as compiling from master - same result:

$ ./searchfs -l
/dev/disk1s5 (apfs): /
/dev/disk1s1 (apfs): /System/Volumes/Data
/dev/disk1s4 (apfs): /private/var/vm
/dev/disk2s2 (hfs ): /Volumes/TimeMachine

$ ./searchfs -v / USBDriverKit.framework$
/System/DriverKit/System/Library/Frameworks/USBDriverKit.framework
/System/Library/Frameworks/USBDriverKit.framework

$ ./searchfs -v /System/Volumes/Data foo
Not a volume mount point: /System/Volumes/Data

$ ./searchfs -v /dev/disk1s1 foo
Not a volume mount point: /System/Volumes/Data

Not sure if it matters, but I also tried granting the binary Full Disk Access, which did not make any difference. Am I doing something wrong?

one of my common workflow scripts searches for all .app files in /Applications and then processes them.

Currently I do this:

mdfind -onlyin /Applications "kMDItemFSName == *.app"

real 0m1.009s
user 0m0.023s
sys 0m0.027s

an slower alternative would be:

find "/Applications" -iname "*.app" -exec echo {} \;

real 1m20.565s
user 0m6.577s
sys 0m29.990s

however searchfs is even slower than this as i have to scan the whole volume and filter the results:

searchfs ".app" | grep -E "^/Applications.+app$"

real 2m7.277s
user 0m0.108s
sys 0m46.177s

So it would be useful if searchfs could operate on the cwd or a directory passed as an argv?