Update of bug #50859 (project findutils): Assigned to: None => berny
_______________________________________________________ Follow-up Comment #1: find(1) supports BTRFS like any other file system type: there is nothing special implemented in the code. Instead, it looks at the entries in "/proc/self/mountinfo" to find the device id. Thus, "find -fstype btrfs" works ... as long as you search in the root of an BTRFS file system: the underlying stat() system call returns a different device number for BTRFS snaphots and BTRFS subvolumes, and these can not be found in the above mentioned mountinfo file: $ stat -c "%d %n" /mnt /mnt/_subvol /mnt/.snapshot 38 /mnt 40 /mnt/_subvol 41 /mnt/.snapshot See also https://savannah.gnu.org/bugs/?50326 Also other tools like "df -T" are not able to display the file system type. $ df --output=fstype,target /mnt /mnt/_subvol /mnt/.snapshot Type Mounted on btrfs /mnt - /mnt/_subvol - /mnt/.snapshot Now, we could only add a workaround for this BTRFS - let's call it - "anomaly" to find(1): if it doesn't find a file system type for a given path, and the next one higher in the hierarchy is a BTRFS, then it could assume that the current entry is on a BTRFS snapshot or BTRFS subvolume. I have such a hack in my local git tree, but didn't publish it yet (as I usually do not use BTRFS at all, thus lacking tests). What do others think about such a (hacky?) workaround? _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?50859> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/