Hacker News Reader

Comment by donatj | Hacker News Reader

I’ve been sad since they were introduced that they don’t work at the file system level, hence not in CLI applications. Support for them in desktop apps that open directories is also spotty.

I would LOVE them if they were reimplemented as a fuse style file system instead of a userland macOS trick.

View on HN

I wonder if there is a list somewhere around Apple of "Annoying Edge Cases We'd Have To Support If Smart Folders Worked At The Filesystem Level", and how long it is.

Like, you're in a smart folder that contains files whose name includes "foo", and you try to create a file whose name does not include "foo", what happens? Do you get an existing filesystem error? Do you get a new "can't create new files in smart folders" error?

Interestingly enough I just discovered that if you drag a file into the Tags section of the Finder window's sidebar, it will remain where it is - but if you create a smart folder whose criteria is "tag:tagname" it won't let you drag anything into it, even though it shows the exact same set of files.

Presumably a "smart directory" would itself be read-only, as if mounted from an ROFS; but its contents would all be symbolic links, such that when you're opening the file, you're opening its readlink(2) target, so the fact that the source link was read-only doesn't matter to your ability to modify the file.

This would pretty much match the expectations of how "Smart Folders" currently work in the Finder, and also how equivalents like "Smart Playlists" work in iTunes/Music.

Also, duplicate filenames due to two files in two different locations both getting picked up by the smart folder.

Ooh, good one. Not a problem when it’s GUI-only, with the little display of the precise path at the bottom when you click it, but disambiguating this for CLI use requires a whole new approach.

You can easily tack on a random ID to the file name in that case and since it would just be a symlink it wouldn’t matter.

That's not the point. I have no doubt that the people at Apple are able to solve these issues. I think a lot of people on HN are able to propose solutions to many of these issues.

The point OP was making is that they have probably did their due diligence and subsequently decided that it ain't worth doing.

Oh for sure. I also imagine it depends on which team proposed it. If it’s the Finder team it might not occur to them to offload it to the file system team because it’s a fancy add on, not a system level thing. I have never used this feature but might give it a go. Having all the PDF files in one place could actually be fairly useful. Could also be nice to combine this with my Dropbox photography workflow.

I think it would be relatively easy to write a MacFUSE driver that uses the mdfind APIs to provide a fake directory of symlinks to the actual files. I might give it a shot. Sounds like a nice side project.

"hence not in CLI applications" is that specific aspect accurate? I'm no longer mac user but thought mdfind (https://ss64.com/osx/mdfind.html) was the command line version of what smart folders use. Not the same as a filesystem but usable for many CLI apps.

You could probably write a wrapper that uses the plist + spotlight (mdfind) to get a functional wrapper.

That being said, I agree that support should be native.

Reply on news.ycombinator.com