Re: from sidebar to NSURLDocumentIdentifierKey

2017-07-26 Thread Jorgen Lundman 

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:

Re: from sidebar to NSURLDocumentIdentifierKey

2017-07-26 Thread Jim Luther 
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:
>>> 
>>>

Re: from sidebar to NSURLDocumentIdentifierKey

2017-07-26 Thread Jorgen Lundman 

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

Re: from sidebar to NSURLDocumentIdentifierKey

2017-07-26 Thread Jim Luther 
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

2017-07-25 Thread Jorgen Lundman 

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