`Alias.for_file` creates an `Alias` object which cannot be written due to containing out of range CNIDs

[hakanai]

Currently, if I use Alias.for_file to produce an alias pointing to a file, it produces an Alias object, but then calling to_bytes() on that object fails.

On closer inspection, the generated cnid_path contains a couple of IDs which are out of range for an unsigned 32-bit int.

% python3       
Python 3.9.6 (default, Sep 26 2022, 11:37:49) 
[Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from mac_alias import Alias
>>> a = Alias.for_file("/Applications")
>>> a.target.cnid_path
[2, 1152921500311879701, 1152921500312727487]
>>> a.to_bytes()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "~/Library/Python/3.9/lib/python/site-packages/mac_alias/alias.py", line 754, in to_bytes
    self._to_fd(b)
  File "~/Library/Python/3.9/lib/python/site-packages/mac_alias/alias.py", line 636, in _to_fd
    cnid_path = struct.pack(
struct.error: 'I' format requires 0 <= number <= 4294967295
>>> 

I don't know what the CNID path is supposed to contain, but I'm guessing that 2 is the ID for /Applications (it's about as small as I'd expect /Applications to have) and the other two are presumably whatever macOS considers to be the parent.

If I look at carbon_path, that contains "Data:..:\x00..:\x00..:\x00Applications".

This is with current main branch, running on macOS Monterey.

We use this as part of building DMGs in our build as well, and those still seem to be working, so it could be that our build machines are still running an earlier version of macOS which is not affected. (Or, it could be we're getting an earlier version of mac_alias which doesn't have the issue, but that seems less likely.)

[hakanai]

a.target.posix_path contains "/../../../Applications"

1152921500311879701 = FFF FFFF 0000 0015
1152921500312727487 = FFF FFFF 000C EFBF

The CNID is being obtained by querying for ATTR_CMN_OBJID.

The docs -

An fsobj_id_t structure that uniquely identifies the file system object
...
If the VOL_CAP_FMT_64BIT_OBJECT_IDS capability is set,
this is instead a 64-bit object identifier.

fsobj_id_t itself is:

typedef struct fsobj_id {
	u_int32_t		fid_objno;
	u_int32_t		fid_generation;
} fsobj_id_t;

In _decode_attrlist_result, I found:

    if attrs[0] & ATTR_CMN_OBJID:
        a = fsobj_id_t.from_buffer(buf, offset)
        offset += sizeof(fsobj_id_t)
        result.append(a)

So _decode_attrlist_result will return the result as an fsobj_id_t, which seems right so far.

But then the way the value is used is:

                info = osx.getattrlist(os.path.join(vol_path, head), attrs, 0)
                cnid_path.append(info[0])

So at this point I give up trying to figure out what's going on - it seems like the struct should be appended to the path list here, but what I see getting appended is definitely just a number.

[hakanai]

Okay, I think I was just misreading. The code wasn't fetching ATTR_CMN_OBJID, but ATTR_CMN_FILEID, which is just a single 64-bit value. Then it's trying to put it into a 32-bit int.

So I dunno, maybe if those two IDs are equivalent, ATTR_CMN_OBJID could be fetched instead? The docs seem to say that they might look related, but should not be assumed to be.

[dnzeek]

I have the same problem. It seems that the struct.pack might need to use ">%uQ" to allow for larger integers?

>>> a.target.cnid_path
[8314680, 6895534, 6895531, 524091, 23684, 2, 1152921500311879701, 1152921500312402187]
>>> struct.pack(">%uQ" % len(a.target.cnid_path), *a.target.cnid_path)
b'\x00\x00\x00\x00\x00~\xdf8\x00\x00\x00\x00\x00i7\xae\x00\x00\x00\x00\x00i7\xab\x00\x00\x00\x00\x00\x07\xff;\x00\x00\x00\x00\x00\x00\\\x84\x00\x00\x00\x00\x00\x00\x00\x02\x0f\xff\xff\xff\x00\x00\x00\x15\x0f\xff\xff\xff\x00\x07\xf9\x0b'
>>>

[al45tair]

So, for HFS and HFS+, which is where this code started out, file IDs are only 32 bits. My guess is that what you're seeing here is APFS (or some other filesystem you're using) handing back 64-bit IDs.

[dnzeek]

@al45tair
Yes. My Mac system is using APFS. How can mac_alias be used on APFS? I think its the default format used on Macs since High Sierra.

[al45tair]

So there's a limit to how much I can help with this, but I would imagine that the right thing here is probably to not fill in the CNID fields unless the file is on HFS/HFS+.

[dnzeek]

Sorry. I don't understand. Where would one specify the content of the CNID fields? My need is to use mac_alias to open alias files and get the path to the actual file.

[hakanai]

If you're only reading the alias files, then you don't have this problem, because this problem only occurs when writing the files.