Re: from sidebar to NSURLDocumentIdentifierKey
Re: from sidebar to NSURLDocumentIdentifierKey
- Subject: Re: from sidebar to NSURLDocumentIdentifierKey
- From: Jim Luther <email@hidden>
- Date: Wed, 26 Jul 2017 18:42:41 -0700
What version of the system? I've been told the dev seeds have a bug in this
area.
> On Jul 26, 2017, at 5:10 PM, Jorgen Lundman <email@hidden> wrote:
>
>
> Jim,
>
> I have created an alias to "fs2", called "fs2 alias" in Desktop. I have no
> problems following (double clicking) the alias after reboots. Even reboots
> where a removed "fs2" comes back to the sidebar.
>
>
> There is one other thing I had noticed is broken, but I hesitate to mention
> it in case it just adds confusion (ie, another unrelated problem we need to
> fix later).
>
> Feel free to ignore this following section:
>
>
> The sidebarlist.plist can also have an "Alias" section, as well as
> "Bookmark". But the alias section is not always present, so I assume the
> magic is in the Bookmark. But, there is something curious in Alias's data:
>
> A working HFS entry's alias's data field:
>
> 00000040 00 14 00 09 00 54 00 65 00 73 00 74 00 65 00 72 |.....T.e.s.t.e.r|
> 00000050 00 20 00 48 00 44 00 0f 00 14 00 09 00 54 00 65 |. .H.D.......T.e|
> 00000060 00 73 00 74 00 65 00 72 00 20 00 48 00 44 00 12 |.s.t.e.r. .H.D..|
> 00000070 00 00 00 13 00 01 2f 00 ff ff 00 00 |....../.....|
>
> My filesystem's section:
>
> 00000040 00 66 00 73 00 33 00 0f 00 08 00 03 00 66 00 73 |.f.s.3.......f.s|
> 00000050 00 33 00 12 00 00 00 13 00 11 2f 56 6f 6c 75 6d |.3......../Volum|
> 00000060 65 73 2f 42 4f 4f 4d 2f 66 73 33 00 ff ff 00 00 |es/BOOM/fs3.....|
>
> First difference is HFS has just volume name "Tester HD" and the other has
> the mountpoint "/Volumes/BOOM/fs3". Curious.
>
> But also, the HFS entry is 2-byte chars (utf16?) whereas mine is single
> byte chars, but only on the volume name, the filesystem name is "correct".
>
> AFAIK, the only places to query VolumeName is vfs_getattr() and calling
> "Filesystem/fs.bundle/fs.util -p" - both which are single byte chars. So it
> is curious that the working HFS somehow ends up with 2 byte chars.
>
> When trying to parse the Alias data, it will fail as the string length 36,
> being longer than the rest of the data, presumably because the length 18
> (0x12) as been doubled in anticipation of 2 byte chars...
>
> Lund
>
>
> Jim Luther wrote:
>> As things work today...
>>
>> When a user drags a file system volume out the Devices sidebar list, the
>> Visibility is set to NeverVisible for that device in the list (as you can
>> see below). The Bookmark is a URL bookmark object (serialized) used to
>> determine which file system volume should be hidden in the future. After
>> reboot, the Bookmark is resolved to find the file system volume. If the
>> entry is NeverVisible, that file system volume is not shown in the Devices
>> sidebar list. So, it sounds like the Bookmark to your device (file system
>> volume) don't resolve between boots (or maybe between unmounts and remounts).
>>
>> What happens if you create a Finder Alias file to your filesystem, reboot,
>> and then attempt to resolve the Finder Alias file? i.e.
>>
>> 1 - Select your file system volume in the Finder.
>> 2 - Use File->Make Alias (command-L) to create a Finder Alias file.
>> 3 - Reboot
>> 4 - Open (double-click) the Alias file in the Finder.
>>
>> It should resolve to your file system volume and open it in a Finder window.
>> If it doesn't, let's continue to talk.
>>
>> - Jim
>>
>>> On Jul 25, 2017, at 10:08 PM, Jorgen Lundman <email@hidden> wrote:
>>>
>>>
>>> Hello list,
>>>
>>> The issue that started it:
>>>
>>> Finder has a sidebar, showing all the mounted devices. You can drag one of
>>> these devices out to "remove" it, and Finder won't bother to show it again,
>>> after reboots etc. This does not work for us, each reboot brings back the
>>> device/mount.
>>>
>>>
>>> Best guess is that it is the
>>>
>>> ./Library/Preferences/com.apple.sidebarlists.plist
>>>
>>> file that controls this, and when you remove a device (fs2 in this case) it
>>> adds an entry for it:
>>>
>>> <key>CustomItemProperties</key>
>>> <dict>
>>> <key>com.apple.LSSharedFileList.TemplateSystemSelector</key>
>>> <integer>1935821166</integer>
>>> </dict>
>>> <key>EntryType</key>
>>> <integer>261</integer>
>>> <key>Name</key>
>>> <string>fs2</string>
>>> <key>Visibility</key>
>>> <string>NeverVisible</string>
>>> <key>Bookmark</key>
>>> <data>
>>> $BASE64
>>> </data>
>>>
>>> Inside the $BASE64 data, best guess is that this is the line:
>>>
>>> NSURLDocumentIdentifierKey:
>>>
>>> da47360e295885ecd68baeb6197af4a6f5745705;00000000;00000000;0000000000000020;com.apple.app-sandbox.read-write;00000001;32000006;0000000000000002;/volumes/boom/fs2
>>>
>>> and this value appears to change between boots:
>>>
>>> d28986a7141072273d5c69996b92d5e909e49a32;00000000;00000000;0000000000000020;com.apple.app-sandbox.read-write;00000001;32000006;0000000000000002;/volumes/boom/fs2
>>>
>>> So if all those guesses are good, the next question is then, how does
>>> NSURLDocumentIdentifierKey produce it. There is practically no information
>>> on it that I can find.
>>>
>>> I do suspect that it sets UF_TRACKED on the mountpoint (/volumes/boom/fs2)
>>> and using ATTR_CMN_DOCUMENT_ID to get something persistent.
>>>
>>> But I can confirm that we handle UF_TRACKED, and set va_document_id
>>> consistently, between boots:
>>>
>>> zfs_setattr_generate_id: 'fs2' -> 3779942736 (0xE14D5950)
>>>
>>> zfs_setattr_generate_id: 'fs2' -> 3779942736 (0xE14D5950)
>>>
>>>
>>> I also compiled the hfs/test/test-doc_tombstone.c file, which passes
>>> without causing asserts. So I feel confident that we handle DOCUMENT_ID as
>>> expected.
>>>
>>> So perhaps NSURLDocumentIdentifierKey mixes in some other information to
>>> generate its identifier?
>>>
>>> Are there any hints as to what it could be?
>>>
>>> Am I even barking at the right tree, looking at
>>> sidebarlists.plist:bookmark:data:unknownbinaryblob ?
>>>
>>> Lund
>>>
>>>
>>> --
>>> Jorgen Lundman | <email@hidden>
>>> Unix Administrator | +81 (0)90-5578-8500
>>> Shibuya-ku, Tokyo | Japan
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Filesystem-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>
> --
> Jorgen Lundman | <email@hidden>
> Unix Administrator | +81 (0)90-5578-8500
> Shibuya-ku, Tokyo | Japan
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden