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 11:14:32 +0900
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.lundman.net EFE4C128E98
ProductName: Mac OS X
ProductVersion: 10.12.5
BuildVersion: 16F73
But the trouble ticket is for older systems. But I suppose it does not help
me to try to debug it on a system where it is not working.
Lund
Jim Luther wrote:
> 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
>>
>
>
--
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