April 3, 20188 yr Currently, shfs gives non-stable (they appear to be incrementing) inode numbers for stat() calls. This results in some problems in applications that assume inode changes indicate file content changes. For instance, nano warns about the file having changed when saving if its inode has changed, and git considers an inode change to be a tree change for some purposes, which can prevent some operations from succeeding. Passing through the inodes from the underlying disk does potentially create a problem of multiple files in /mnt/user sharing the same inode. This could be worked around by returning `underlying_inode * nb_data_drives + drive_idx` (which is potentially problematic if the drive is near the 64-bit limit on inodes, but that seems extremely unlikely, and you'd have the same issue with incrementing-at-read-time inodes anyway).
Archived
This topic is now archived and is closed to further replies.