Closed sbond75 closed 4 months ago
@sbond75 can you post the output of these:
hfsfuse -v
sudo ./hfsdump /dev/sdf2 xattr /Downloads/.DS_Store
sudo ./hfsdump /dev/sdf2 stat /Downloads/.DS_Store
I'm mostly looking to see if the second command lists an com.apple.decmpfs attribute and whether zlib or lzfse appear in the first. Files that use HFS+'s compression mechanism have no extents, but if hfsfuse can't decompress those the size ought to be 0 and it looks like from your trace that it's 8196, so I'm wondering if it's a bug with decmpfs handling.
Here is is:
$ ./hfsfuse -v
hfsfuse version 0.214-529cb8b
Built with:
FUSE API v2.9
libhfs RCSID $NetBSD: libhfs.c,v 1.19 2023/08/11 05:51:34 mrg Exp $
ublio v0.1
utf8proc v2.9.0
zlib v1.3.1
lzfse
$ sudo ./hfsdump /dev/sdf2 xattr /Downloads/.DS_Store
$ echo $?
0
$ sudo ./hfsdump /dev/sdf2 stat /Downloads/.DS_Store
path: /Downloads/.DS_Store
type: file
flags: 130
cnid: 397670
date_created: Sat May 22 15:40:20 2021
date_content_mod: Wed Apr 17 14:17:35 2024
date_attrib_mod: Wed Apr 17 14:17:35 2024
date_accessed: Wed Apr 17 16:12:40 2024
date_backedup: Wed Dec 31 19:00:00 1969
encoding: 0
permissions.owner_id: 501
permissions.group_id: 20
permissions.admin_flags: 0
permissions.owner_flags: 0
permissions.file_mode: 100644
permissions.special: 1
user_info.file_type:
user_info.file_creator:
user_info.finder_flags: 16400
user_info.location: 0, 0
finder_info.extended_finder_flags: 0
finder_info.put_away_folder_cnid: 217
data_fork.logical_size: 34820
rsrc_fork.logical_size: 0
Thanks, that rules out compression. Nothing looks unusual about the record info from hfsdump stat either.
If there weren't any messages like "read of x bytes at offset y failed (block size z)" or any other errors when you ran hfsdump read, then I think that narrows it down to a problem locating the extent records themselves in hfslib_get_file_extents
. This will be a bit tricky to debug, but if it'd be possible to set a breakpoint there and step until this jumps to the error label, that would tell us where exactly this is failing. What this function is trying to do is locate and read the list of byte offsets (extents) that tell it where to read the actual file data off the filesystem.
Just to be sure, it might be worth first rebuilding with make WITH_UBLIO=none
and re-running the hfsdump read command. This won't resolve it if the issue is with the extents but it should rule out any issues at the read layer.
I was able to reproduce this. It's a bug during the extents lookup mentioned above that's causing the search to be cancelled early with no results when it shouldn't be, specifically at this point https://github.com/0x09/hfsfuse/blob/5a7de8c4bde3daaca12e70eda4e723ca33f36fe2/lib/libhfs/libhfs.c#L653-L658 The Apple driver also confirms this shouldn't be the case here.
I'll need to debug this a bit more but should be able to sort it out now that I have a repro.
Edit: found the issue, this ought to fix it https://github.com/0x09/hfsfuse/commit/cc49395548d97d94e22e350f596895d3b8ccc51b
The fix works, thanks!
For some .DS_Store files and a zip file on an HFS+ drive I've been copying from, the
read
syscall fails with EPERM:This file is readable when using the hfsplus driver on Linux and has some binary content, so it seems to be an hfsfuse issue. Upon checking with hfsdump with
sudo ./hfsdump /dev/sdf2 read /Downloads/.DS_Store
, it returns exit code 255. I used gdb on it and found thathfslib_get_file_extents
was returning 0, meaning there are no extents for the file but there should probably be extents?How can this be debugged further?