> > So far I hadn't had much lack in scanning by this order, sparse filesystem > makes the /.vol/<fsid>/<fileid> option inefficient. > As for the searchfs option, I haven't seen in the man page any way to > control the order of the files. >
The order is arbitrary, as it walks over the btree nodes in the most efficient manner, and that btree's order can change. Still, if you want to keep the scan persistent between boots, a persistent hashmap of the IDs is still the best option, IMO, as this lets you determine which items you have already seen in a previous scan. Of course, this means that you'll have to save the entire map regularly (and with backups in place in case you crash during the save process) to protect yourself against system crashes during your scan. Be advised that searchfs is fairly fast if you only want to learn all used fileID first, without actually learning the paths, yet. You can specify that you want a large number of fileIDs returned in one go, so you can, for instance, request chunks of a few 1000 IDs per call, then add them to your hashmap, and save that map every few seconds if you're concerned about system crashes (which I find rather unlikely to happen unless your program runs in environments where this is more likely). Once you have gathered all IDs (which may be in the range of a million, easily), you can start requesting each ID's path and file attributes. Hit me up privately if you need help with using searchfs. Thomas
_______________________________________________ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
