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 > _______________________________________________ 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
