> On Mar 21, 2018, at 1:38 PM, Irad K <iradizat...@gmail.com> wrote: > > Eric, > > Thanks for the info, that can explain the offset since I previously upgraded > the OS from Sierra which uses HFS+ for its root filesystem. > > The reason that brought me looking into the fileid values, is some file > scanner design I'm currently working on that instead of iterating the files > according to their directory structure (i.e. BFS), I iterate according to > ascending file-id attribute, where I always assumed that the file-id starts > from zero. > > Using this scanning order, I can halt my scanning and regain to it according > to the last scanned file-id (assuming that I can ignore newly created files > that got file-id value lower than this last scanned value). > > I'd be happy if you could tell me what is the file-id allocation policy in > APFS or HFS+ in the following aspects > > 1. Is there any way to extract the current file-id range (minimum to maximum > fileid).
No, and it’s unlikely that there will ever be one. Functionally, the most useful way to think about file ID’s is a UUID’s . Their value implies gives you NO useful information about the file, aside from the fact that it’s a unique ID for the file. > 2. I've noticed that there are some gaps in file-id list. meaning that some > ids aren't connected to files. How can this happen (I assume it’s due to > deleted files), and when creating new file, does it get file-id from the > lowest available value or the next file-id after the current maximum value. FIle deletion, arbitrary action, dumb luck… Again, the file ID is effectively a unique identifier for the file. The fact that APFS HAPPENS to hand them out in a particular order is an artifact of it’s implementation, not a requirement. > 3. I’d like to use an array that each index represent a file-id. Why? I can’t think of any real use for doing this. Thomas’s idea of using a dictionary isn’t a bad one if this is a problem you really need to solve, but this seems like a very strange problem to decide you need to solve. > Can I assume that the file-ids aren’t sparse (meaning that the gaps of unused > id values are small) so that I won't waste too much memory ? No, not at all. Over time it would be normal and expected for the list to become quite sparse- some files are written out early in the drives life and basically never change. Just looking in my /Applications directory, the Info.plist of the oldest app on my system was last modified on “July 17, 2006”. A lot of files have come and gone since 2006… > 4. Do you recommend other, more efficient way to iterate through the files in > order to ascending file-id, other than through the /.vol/ drive ? Well, I’m not sure I’d recommend using .vol either… What are you trying to do, and why does iterating by file ID seem like a good way to do it? -Kevin _______________________________________________ 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
