Re: [toolbox] Extended Attributes

[Adam R. M. <ama...@ma...>]

On Jul 6, 2005, at 07:18, J=E9r=F4me Laurens wrote:

>
> Le 6 juil. 05, =E0 15:19, someone wrote, but I've lost the quoting =20
> hierarchy
>
>
>>>>
>>>>
>>>>> If you store aliases as data in a plist, though (BDAlias is =20
>>>>> handy for this), renaming isn't a problem for the front-end =20
>>>>> specific info.
>>>>>
>>>>>
>>>>
>>>> Ooo, that sounds much nicer than hard coded links at the top of =20
>>>> the document...(even if they are relative)
>>>>
>>>>
>>>
>>> This is not a portable solution. Aliases are mac specific.
>>> A solution viable on other systems must also be considered
>>>
>>
>> Personally, I don't care about other systems, but if they must be =20
>> considered for the mactextoolbox, why not add another piece of =20
>> metadata?  Store a path and an alias in the plist.
>>
>
> In fact, I did not only mean different operating systems.
>
> What will happen if I duplicate a file, for example by copying it =20
> on a USB memory key, then copy it on my home computer, then copy it =20=

> back. What is the location pointed to by the alias? It might be =20
> consistent but not correct.
> This is an example where the path can be correct but the alias can =20
> be broken.
> On the other hand, changing a file name will break the stored path =20
> but not the alias.
>
> So a good solution might be to store both the file and the alias, =20
> use the relative path and if it appears to be corrupted, the alias.
>
> This is a siuation were mac aliases are not that superior to sym =20
> links...

Yes, this is why you have to prefer paths to aliases if both exist (I =20=

think the OS implementation of aliases does this also, after 10.2?).

>>>> [...]
>>>> it sounds like a "checksum" string at the end of the document =20
>>>> that is unique for each encoding (is this even possible?) is the =20=

>>>> only way to do it if the information is going to be kept in-file.
>>>>
>>>>
>>>
>>> Or an ascii name?
>>>
>>
>> If you can write into the byte stream without corrupting it...
>>
>
> Isn't there already strong 16 bits and 32 bits BOM?
> I still don't understand what really exist on that matter.

BOM only tells you if you have big-endian or little-endian data: =20
<http://www.unicode.org/faq/utf_bom.html#BOM>, and they say that you =20
can use it to differentiate between the different UTF variants.  I =20
think the main problem is that it isn't always present (and of course =20=

it doesn't help with legacy encodings).

Adam