1

I am able to get the inode / system file number from a path in Swift like so:

try(print(FileManager.default.attributesOfItem(atPath:myFilePath)[.systemFileNumber]!))

However, I am not sure how I can do the opposite - retrieve the file path from the inode number. On the command line there is the magic .vol directory as discussed here, but that would be fiddly/inefficient to use programmatically.

I do not need to open the file, just get the path in the most efficient way possible. Essentially, I need to store a list of a 50-500k files, and storing their full paths is very inefficient memory wise and I don't usually need to refer back to them, so I want to store just their inode values to then look them up if needed.

Tom Anthony
  • 791
  • 7
  • 14
  • 1
    I don't think that's possible https://unix.stackexchange.com/q/92816/32043 – Alexander Mar 24 '21 at 14:24
  • 1
    500k files, assuming 40 byte-long-paths is still only like 20 MB of memory, no big deal. If memory really is right, you could optimize this with [a prefix tree](https://en.wikipedia.org/wiki/Trie). Alternatively, have you taken a look at the bookmark APIs? If you [make a bookmark out of a URL](https://developer.apple.com/documentation/foundation/nsurl/1408344-bookmarkdata), how large is the resulting `Data`? – Alexander Mar 24 '21 at 14:27
  • Thanks, @Alexander. It is confusing to me, as it is definitely possible via the command line via the 'magic' `.vol` folder, and some apps do use the inode to track files, so it must be somehow, you'd think. – Tom Anthony Mar 24 '21 at 14:28
  • The paths are quite deeply nested, so may be 100-150 characters, but having tried it since I asked, it isn't as bad as I thought. It comes out at ~140mb or so in memory. That isn't a dealbreaker, but just seems inefficient for the modest nature of what my app does. I did look at the Bookmark stuff, which I found later, but they are larger than the actual path. I wonder if I could abuse that by sending the `.vol` paths to back my way into the true path. :-/ – Tom Anthony Mar 24 '21 at 14:32
  • Short of anything else, a prefix tree looks like a pretty quick/easy fix for this. Or even easier, if all these paths are nested relative to a few paths, you can just store the relative components, and resolve them as you iterate through – Alexander Mar 24 '21 at 17:02

0 Answers0