Re: [toolbox] Extended Attributes

[<jer...@u-...>]

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 handy=20=

>>>> for this), renaming isn't a problem for the front-end specific=20
>>>> info.
>>>>
>>>
>>> Ooo, that sounds much nicer than hard coded links at the top of the=20=

>>> 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 on a=20=

USB memory key, then copy it on my home computer, then copy it back.=20
What is the location pointed to by the alias? It might be consistent=20
but not correct.
This is an example where the path can be correct but the alias can be=20
broken.
On the other hand, changing a file name will break the stored path but=20=

not the alias.

So a good solution might be to store both the file and the alias, use=20
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...


>
>>>
>>> [...]
>>> it sounds like a "checksum" string at the end of the document that=20=

>>> is unique for each encoding (is this even possible?) is the only way=20=

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