> support, which are both unavailable as configuration options in the > I couldn't get it to work, even when manually compiling in Spotlight > Having tried to replicate the steps of a Linux installation on FreeBSD, > able to search quickly and taking that feature away puts you squarely > although it's lacking Spotlight support. Netatalk works beautifully through the installed port, > customer server on a FreeBSD base and it has been remarkably stable the > server OS a couple of years ago, I have implemented every single > to this) is a hard requirement for office file servers, I am looking how > contents or metadata, although macOS users have become quite accustomed > As quick server-side search for file names (not necessarily file > and instructions to getting it to work are Linux-only > macOS users as of now, as it's missing truly working Spotlight support > protocol some time ago, Samba appears to be no viable alternative for > The scenario is as follows: although Apple has deprecated the AFP > testing and am now turning to this board to possibly help me along. > I have researched online resources for quite some time now, did my own > search engine, which is more stable and handles millions of files > It would be nice to see the netatalk developers to support another > have a typical file server with hundreds of thousands of files, it will > through you can integrate it with netatalk, it should work then. > You should start with a small volume to index with tracker and if it get > choice for netatalk and neither for samba. > search an relies on many desktop centric software, it wasn't a good Tracker is not a server story, it was written as a desktop > certain PDFs and doesn't finish indexing then, so you end up with no > tracker, which doesn't work beautifully in older versions. > doesn't matter which file server you chose, you end up with gnome > Both Samba and Netatalk base their indexing on tracker. ![]() ![]() I struggle to understand the reasons behind this and would love to hear thoughts on this - or even better: solutions. The thought that it should be easier to search for cat pictures than file names on a non-Windows-based private file server is nonsensical to me. We live in the age of Google and Big Data where unimaginable mountains of data are processed every single second. ![]() It just seems unfathomable to me that no reliable and quick cross-platform solution for such a basic task should exist. In my experience, it's not even content indexing that many users expect but rather to quickly search for file names. Rigid folder structures are no remedy for this as the amount of data just grows exponentially. The issue with this is that it annoys users to such an extent that they move all their working data to their local machines and external hard drives (which are indexed by Spotlight quite well) and leave it there, preventing it from entering scheduled backups. Now we're back to square one: enterprise-scale Windows-only installation to get a simple (as perceived by a user) feature such as quick search on a file server. Since there appears to be no stable indexing mechanism for Unix desktops as well, it appears to me that the only solutions for this very common use-case exist as commercial Windows-based applications. ![]() Given the popularity of macOS among developers and the real need for businesses to quickly search hundreds of thousands of files, I'm more than surprised that I'm hitting walls left and right, front and back on this issue for years now. I am aware that Spotlight is a proprietary extension by Apple that serves little to no use outside of macOS desktop environments. So basically what you’re saying is that useful AFP and SMB sharing for macOS users is limited to macOS Server because no viable stable alternatives for server-side file indexing exist.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |