from sidebar to NSURLDocumentIdentifierKey
from sidebar to NSURLDocumentIdentifierKey
- Subject: from sidebar to NSURLDocumentIdentifierKey
- From: Jorgen Lundman <email@hidden>
- Date: Wed, 26 Jul 2017 14:08:49 +0900
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.lundman.net 8BA90128DA5
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