Re: from sidebar to NSURLDocumentIdentifierKey
Re: from sidebar to NSURLDocumentIdentifierKey
- Subject: Re: from sidebar to NSURLDocumentIdentifierKey
- From: Jorgen Lundman <email@hidden>
- Date: Thu, 27 Jul 2017 09:10:28 +0900
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.lundman.net 728A8125D49
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