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 <lund...@lundman.net> 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 <lund...@lundman.net> 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 | <lund...@lundman.net> >>>> 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 (Filesystem-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/filesystem-dev/luther.j%40apple.com >>>> >>>> This email sent to luthe...@apple.com >>> >>> >> >> -- >> Jorgen Lundman | <lund...@lundman.net> >> Unix Administrator | +81 (0)90-5578-8500 >> Shibuya-ku, Tokyo | Japan >> > > -- Jorgen Lundman | <lund...@lundman.net> 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 (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
