Re: from sidebar to NSURLDocumentIdentifierKey
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 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: >> >> 0040 00 14 00 09 00 54 00 65 00 73 00 74 00 65 00 72 |.T.e.s.t.e.r| >> 0050 00 20 00 48 00 44 00 0f 00 14 00 09 00 54 00 65 |. .H.D...T.e| >> 0060 00 73 00 74 00 65 00 72 00 20 00 48 00 44 00 12 |.s.t.e.r. .H.D..| >> 0070 00 00 00 13 00 01 2f 00 ff ff 00 00 |../.| >> >> My filesystem's section: >> >> 0040 00 66 00 73 00 33 00 0f 00 08 00 03 00 66 00 73 |.f.s.3...f.s| >> 0050 00 33 00 12 00 00 00 13 00 11 2f 56 6f 6c 75 6d |.3/Volum| >> 0060 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 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: CustomItemProperties com.apple.LSSharedFileList.TemplateSystemSelector 1935821166 EntryType 261 Name fs2 Visibility NeverVisible Bookmark $BASE64 Inside the $BASE64 data, best guess is that this is the line: NSURLDocumentIdentifierKey: da47360e295885ecd68baeb6197af4a6f5
Re: from sidebar to NSURLDocumentIdentifierKey
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 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: > > 0040 00 14 00 09 00 54 00 65 00 73 00 74 00 65 00 72 |.T.e.s.t.e.r| > 0050 00 20 00 48 00 44 00 0f 00 14 00 09 00 54 00 65 |. .H.D...T.e| > 0060 00 73 00 74 00 65 00 72 00 20 00 48 00 44 00 12 |.s.t.e.r. .H.D..| > 0070 00 00 00 13 00 01 2f 00 ff ff 00 00 |../.| > > My filesystem's section: > > 0040 00 66 00 73 00 33 00 0f 00 08 00 03 00 66 00 73 |.f.s.3...f.s| > 0050 00 33 00 12 00 00 00 13 00 11 2f 56 6f 6c 75 6d |.3/Volum| > 0060 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 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: >>> >>> CustomItemProperties >>> >>> com.apple.LSSharedFileList.TemplateSystemSelector >>> 1935821166 >>> >>> EntryType >>> 261 >>> Name >>> fs2 >>> Visibility >>> NeverVisible >>> Bookmark >>> >>> $BASE64 >>> >>> >>> Inside the $BASE64 data, best guess is that this is the line: >>> >>> NSURLDocumentIdentifierKey: >>> >>> da47360e295885ecd68baeb6197af4a6f5745705;;;0020;com.apple.app-sandbox.read-write;0001;3206;0002;/volumes/boom/fs2 >>> >>> and this value appears to change between boots: >>> >>> d28986a7141072273d5c69996b92d5e909e49a32;;;0020;com.apple.app-sandbox.read-write;000
Re: from sidebar to NSURLDocumentIdentifierKey
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: 0040 00 14 00 09 00 54 00 65 00 73 00 74 00 65 00 72 |.T.e.s.t.e.r| 0050 00 20 00 48 00 44 00 0f 00 14 00 09 00 54 00 65 |. .H.D...T.e| 0060 00 73 00 74 00 65 00 72 00 20 00 48 00 44 00 12 |.s.t.e.r. .H.D..| 0070 00 00 00 13 00 01 2f 00 ff ff 00 00 |../.| My filesystem's section: 0040 00 66 00 73 00 33 00 0f 00 08 00 03 00 66 00 73 |.f.s.3...f.s| 0050 00 33 00 12 00 00 00 13 00 11 2f 56 6f 6c 75 6d |.3/Volum| 0060 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 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: >> >> CustomItemProperties >> >> com.apple.LSSharedFileList.TemplateSystemSelector >> 1935821166 >> >> EntryType >> 261 >> Name >> fs2 >> Visibility >> NeverVisible >> Bookmark >> >> $BASE64 >> >> >> Inside the $BASE64 data, best guess is that this is the line: >> >> NSURLDocumentIdentifierKey: >> >> da47360e295885ecd68baeb6197af4a6f5745705;;;0020;com.apple.app-sandbox.read-write;0001;3206;0002;/volumes/boom/fs2 >> >> and this value appears to change between boots: >> >> d28986a7141072273d5c69996b92d5e909e49a32;;;0020;com.apple.app-sandbox.read-write;0001;3206;0002;/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) >>
Re: from sidebar to NSURLDocumentIdentifierKey
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 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: > > CustomItemProperties > > com.apple.LSSharedFileList.TemplateSystemSelector > 1935821166 > > EntryType > 261 > Name > fs2 > Visibility > NeverVisible > Bookmark > > $BASE64 > > > Inside the $BASE64 data, best guess is that this is the line: > > NSURLDocumentIdentifierKey: > > da47360e295885ecd68baeb6197af4a6f5745705;;;0020;com.apple.app-sandbox.read-write;0001;3206;0002;/volumes/boom/fs2 > > and this value appears to change between boots: > > d28986a7141072273d5c69996b92d5e909e49a32;;;0020;com.apple.app-sandbox.read-write;0001;3206;0002;/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 | > 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 ___ 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
from sidebar to NSURLDocumentIdentifierKey
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: CustomItemProperties com.apple.LSSharedFileList.TemplateSystemSelector 1935821166 EntryType 261 Name fs2 Visibility NeverVisible Bookmark $BASE64 Inside the $BASE64 data, best guess is that this is the line: NSURLDocumentIdentifierKey: da47360e295885ecd68baeb6197af4a6f5745705;;;0020;com.apple.app-sandbox.read-write;0001;3206;0002;/volumes/boom/fs2 and this value appears to change between boots: d28986a7141072273d5c69996b92d5e909e49a32;;;0020;com.apple.app-sandbox.read-write;0001;3206;0002;/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 | 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