Mac OS Alias file links

Mac OS Alias file links

[Ken Mankoff]

I use links to files quite often in Org Mode. Either by C-l file: or
drag-and-drop (with smart-dnd). But when files move, the links break.

BibDesk solves this by storing Mac OS Aliases to files. Then if files
move, the alias still works. BibDesk actually stores more:

> The Bdsk-File entries store Mac OS aliases, which contain a file ID
> and absolute path. Bdsk-File entries also store a relative path, which
> is used if the alias is broken.

Is there a way to add this feature to Org Mode? Yes, obviously, since
this is emacs and Org Mode. But has anyone already done this? Any advice
where to start?

Thanks,

  -k.

Fwd: Mac OS Alias file links

[Ken Mankoff]

Hi,

I posted something at the beginning of the week, and have received no
reply. If nobody had anything to say that is fine. But I notice that my
original post on gmane
http://article.gmane.org/gmane.emacs.orgmode/84707 appears blank, so
perhaps the no reply is due to a posting issue. Hence, I send the email
again...

  -k.

On 2014-04-08 at 03:03, Ken Mankoff wrote:
> I use links to files quite often in Org Mode. Either by C-l file: or
> drag-and-drop (with smart-dnd). But when files move, the links break.
>
> BibDesk solves this by storing Mac OS Aliases to files. Then if files
> move, the alias still works. BibDesk actually stores more:
>
>> The Bdsk-File entries store Mac OS aliases, which contain a file ID
>> and absolute path. Bdsk-File entries also store a relative path,
>> which is used if the alias is broken.
>
> Is there a way to add this feature to Org Mode? Yes, obviously, since
> this is emacs and Org Mode. But has anyone already done this? Any
> advice where to start?
>
> Thanks,
>
>   -k.

Re: Fwd: Mac OS Alias file links

[Bastien]

Hi Ken,

Ken Mankoff <mankoff@gmail.com> writes:

> http://article.gmane.org/gmane.emacs.orgmode/84707 appears blank

The article is displayed correctly for me, probably a temporary
issue with gmane.org.

> so perhaps the no reply is due to a posting issue. Hence, I send the
> email again...

I don't use MacOSX so it's hard to know where to start.

Even for those who uses MacOSX, you should perhaps be more specific
on how Org-mode would store such links, then somebody might step up.

Best,

-- 
 Bastien

Re: Fwd: Mac OS Alias file links

[Ken Mankoff]

Hi Bastien,

Thanks for letting me know it displays properly and email received. The
URL works for me this morning too.

On 2014-04-14 at 05:22, Bastien wrote:
> Even for those who uses MacOSX, you should perhaps be more specific
> on how Org-mode would store such links, then somebody might step up.

Aliases are a type of links ("ln" on linux, "shortcut" on Windows
"alias" on OS X (OS X of course also supports "ln")). The difference
between an OS X alias and "ln" is that if the target is moved, the OS X
alias still points to it, and double-clicking on an alias (or issuing
the "open" command in a terminal) will open the target, wherever it
is. I just checked in a VM and Windows Shortcuts also behave this way.

Therefore, if in addition to "file:" there were an "alias:" option, Org
could link to files that move. I think this is a powerful feature. I
imagine "alias:" would be an option when I press C-cl, and a way to set
it as the default when I press C-ucl.

That is, links would be [[alias:foo][FileName]] where "foo" is a string
version (hashed?) of the alias.

In BibDesk, "foo" is ~1200 characters long, and according to the BibDesk
documentation, that ~1200 characters is:

> The Bdsk-File entries store Mac OS aliases, which contain a file ID
> and absolute path. Bdsk-File entries also store a relative path, which
> is used if the alias is broken.

So it looks like an Alias can be hashed some way and stored as just a
string. An example BibDesk entry in by BibTeX file looks like:

@article{citekey,
	Author = {Someone},
	Journal = {Nature},
	Pages = {24--42},
	Title = {{A Paper}},
	Bdsk-File-1 = {YnBsa...etc for 1200 characters...}}

Opening the file with C-o would involve un-hashing it, and then treating
it the same way a "file:" is opened.

I imagine Org would mostly store the links the same way it stores file
links. The change would be that since the link is the alias (long ugly
string), the description would be required, and perhaps default to
/path/to/filename. Although since the whole point is that the /path/to/
can change, perhaps the default name would just be filename.

  -k.

Re: Fwd: Mac OS Alias file links

[Nick Dokos]

Ken Mankoff <mankoff@gmail.com> writes:

> Hi Bastien,
>
> Thanks for letting me know it displays properly and email received. The
> URL works for me this morning too.
>
> On 2014-04-14 at 05:22, Bastien wrote:
>> Even for those who uses MacOSX, you should perhaps be more specific
>> on how Org-mode would store such links, then somebody might step up.
>
> Aliases are a type of links ("ln" on linux, "shortcut" on Windows
> "alias" on OS X (OS X of course also supports "ln")). The difference
> between an OS X alias and "ln" is that if the target is moved, the OS X
> alias still points to it, and double-clicking on an alias (or issuing
> the "open" command in a terminal) will open the target, wherever it
> is. I just checked in a VM and Windows Shortcuts also behave this way.
>
> Therefore, if in addition to "file:" there were an "alias:" option, Org
> could link to files that move. I think this is a powerful feature. I
> imagine "alias:" would be an option when I press C-cl, and a way to set
> it as the default when I press C-ucl.
>
> That is, links would be [[alias:foo][FileName]] where "foo" is a string
> version (hashed?) of the alias.
>
> In BibDesk, "foo" is ~1200 characters long, and according to the BibDesk
> documentation, that ~1200 characters is:
>
>> The Bdsk-File entries store Mac OS aliases, which contain a file ID
>> and absolute path. Bdsk-File entries also store a relative path, which
>> is used if the alias is broken.
>
> So it looks like an Alias can be hashed some way and stored as just a
> string. An example BibDesk entry in by BibTeX file looks like:
>
> @article{citekey,
> 	Author = {Someone},
> 	Journal = {Nature},
> 	Pages = {24--42},
> 	Title = {{A Paper}},
> 	Bdsk-File-1 = {YnBsa...etc for 1200 characters...}}
>
> Opening the file with C-o would involve un-hashing it, and then treating
> it the same way a "file:" is opened.
>
> I imagine Org would mostly store the links the same way it stores file
> links. The change would be that since the link is the alias (long ugly
> string), the description would be required, and perhaps default to
> /path/to/filename. Although since the whole point is that the /path/to/
> can change, perhaps the default name would just be filename.
>

What does emacs do when you C-x C-f an alias?

If it opens it properly (i.e. opens the target file) then why is
anything needed in org? It seems to me that a file: link should just
work.

If it does not, then maybe that's where the capability should be added.
Org seems to be the wrong place for it.

But note that everything I know about aliases, I learnt in the last five
minutes, so I could be way off the mark.

-- 
Nick

Re: Fwd: Mac OS Alias file links

[Ken Mankoff]

On 2014-04-14 at 08:42, Nick Dokos wrote:
> What does emacs do when you C-x C-f an alias?

Alias in OS X (and Shortcut in Windows) present as files. Org treats it
just as it should - as a file. Everything works.

> If it opens it properly (i.e. opens the target file) then why is
> anything needed in org? It seems to me that a file: link should just
> work.
>
> If it does not, then maybe that's where the capability should be added.
> Org seems to be the wrong place for it.
>
> But note that everything I know about aliases, I learnt in the last five
> minutes, so I could be way off the mark.

This requires me to 1) manually make an alias (something I never do), 2)
choose where to store that alias on disk, and then 3) link to the alias
in Org. Worse, the situation is not improved or difference since if the
alias moves, the Org link (to the alias) is broken.

I'm imagining the alias never exists on disk. Just as a representation
inside Org, and pointing to the target file. Now the link can never
break, unless the target is deleted. And there is no additional effort
on our part beyond the existing work to make a link.

  -k.

P.S. How does one make a link to a folder or directory in org? 

Re: Fwd: Mac OS Alias file links

[Achim Gratz]

Ken Mankoff writes:
> Aliases are a type of links ("ln" on linux, "shortcut" on Windows
> "alias" on OS X (OS X of course also supports "ln")). The difference
> between an OS X alias and "ln" is that if the target is moved, the OS X
> alias still points to it, and double-clicking on an alias (or issuing
> the "open" command in a terminal) will open the target, wherever it
> is.

If I understand correctly, this only works through Finder and not from a
shell and POSIX file access functions.  Whether or not Emacs could use
aliases therefore depends on what interface it is using to access files
on MacOS (I have no idea).

> I just checked in a VM and Windows Shortcuts also behave this way.

No, they don't.  Explorer does find the file if you move it into a
subfolder and will ask you to tell it where it went if it doesn't find
it, but any direct access through that shortcut will fail as if the file
didn't exist.  Also, WIndows shortcuts and Windows links are two totally
different things and links don't follow moving targets either.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Fwd: Mac OS Alias file links

[Ken Mankoff]

On 2014-04-14 at 12:26, Achim Gratz wrote:
> Ken Mankoff writes:
>> Aliases are a type of links ("ln" on linux, "shortcut" on Windows
>> "alias" on OS X (OS X of course also supports "ln")). The difference
>> between an OS X alias and "ln" is that if the target is moved, the OS
>> X alias still points to it, and double-clicking on an alias (or
>> issuing the "open" command in a terminal) will open the target,
>> wherever it is.
>
> If I understand correctly, this only works through Finder and not from
> a shell and POSIXfile access functions.  Whether or not Emacs could
> use aliases therefore depends on what interface it is using to access
> files on MacOS (I have no idea).

When you say "this only works" I'm not sure what you are referring to. I
assume creation and/or access.

* Creation 

Yes creating Aliases is a Finder function, although creation can be
scripted from the shell through the "osascript" CLI utility provided on
OSX.

* Access

Some access works through the shell.

If I make a link to an alias in Org, opening the link works and is
handled by the system for all the different types of files I can create
an alias to.

But an alias is not like an "ln"-like link. It presents to the OS as its
own file, so if you try to edit an alias to a plain text file, you get a
bunch of garbage (the alias), not the plain text file.

In my fantasy, the link wouldn't be to an alias file, it would *contain
the alias* the way the BibDesk field does. Therefore C-o on an "alias:"
link would require extra code: Decode the alias, then pass it off to the
system.

>> I just checked in a VM and Windows Shortcuts also behave this way.
>
> No, they don't.  Explorer does find the file if you move it into a
> subfolder and will ask you to tell it where it went if it doesn't find
> it, but any direct access through that shortcut will fail as if the
> file didn't exist.  Also, WIndows shortcuts and Windows links are two
> totally different things and links don't follow moving targets either.

My system is different. I'm not sure why. I have an XP VM. I created a
"New Text Document" file on the desktop. I right-click, and select
"Create Shortcut". I have a new shortcut on the desktop. I moved the
original file elsewhere (C:\, "My Documents", etc. not just subfolders),
double-clicked on the shortcut (still on Desktop), and the original file
opened. I could edit and save it and saves were placed into the
relocated file. If "direct access" you mean POSIX-level access, then
perhaps. I don't know. But I think emacs can operate on files at a
higher level. 

  -k.

Re: Fwd: Mac OS Alias file links

[Charles Berry]

Ken Mankoff <mankoff <at> gmail.com> writes:

> 
> 
> On 2014-04-14 at 12:26, Achim Gratz wrote:
> > Ken Mankoff writes:
> >> Aliases are a type of links ("ln" on linux, "shortcut" on Windows
> >> "alias" on OS X (OS X of course also supports "ln")). The difference
> >> between an OS X alias and "ln" is that if the target is moved, the OS
> >> X alias still points to it, and double-clicking on an alias (or
> >> issuing the "open" command in a terminal) will open the target,
> >> wherever it is.
> >
[...]

> In my fantasy, the link wouldn't be to an alias file, it would *contain
> the alias* the way the BibDesk field does. Therefore C-o on an "alias:"
> link would require extra code: Decode the alias, then pass it off to the
> system.
> 

The point of using an alias rather than a filename or the name of a 
symbolic link that points to the file is that it inherits the property
of Mac OS X aliases that moving the file does not break the alias ---
it still points to file.

For this to work as you fantasize, you would need to enable the Finder 
application to modify the part of the *.org file that encodes the alias 
when you change the location of the aliased file just as the Finder 
does to the alias when the location of the aliased file is modified in the 
Finder.

That is a heavy lift.

OTOH, writing an AppleScript to make an alias in a folder that is never 
moved, writing elisp to call that script and then make an org-mode link to 
the alias just created might work for you.

HTH,

Chuck

Re: Fwd: Mac OS Alias file links

[Ken Mankoff]

On 2014-04-14 at 13:42, Charles Berry wrote:
> The point of using an alias rather than a filename or the name of a
> symbolic link that points to the file is that it inherits the property
> of Mac OS X aliases that moving the file does not break the alias ---
> it still points to file.

Exactly!

> For this to work as you fantasize, you would need to enable the Finder
> application to modify the part of the *.org file that encodes the
> alias when you change the location of the aliased file just as the
> Finder does to the alias when the location of the aliased file is
> modified in the Finder.

I don't think so. I'm not sure how BibDesk handles it, but my BibTeX
file is not modified when I move the PDF that is linked to an entry via
that 1200 character field that encodes the alias. Clearly BibDesk does
something neat to encode and decode that field, but once created, the OS
nor Finder know anything about that line or the file containing it. I
don't think Finder would need to know about a string in an Org file
either.

> OTOH, writing an AppleScript to make an alias in a folder that is
> never moved, writing elisp to call that script and then make an
> org-mode link to the alias just created might work for you.

Yes this would work too as a hack.

  -k.

Re: Fwd: Mac OS Alias file links

[Ivan Andrus]

On Apr 14, 2014, at 12:36 PM, Ken Mankoff <mankoff@gmail.com> wrote:

> On 2014-04-14 at 13:42, Charles Berry wrote:
> 
>> For this to work as you fantasize, you would need to enable the Finder
>> application to modify the part of the *.org file that encodes the
>> alias when you change the location of the aliased file just as the
>> Finder does to the alias when the location of the aliased file is
>> modified in the Finder.
> 
> I don't think so. I'm not sure how BibDesk handles it, but my BibTeX
> file is not modified when I move the PDF that is linked to an entry via
> that 1200 character field that encodes the alias. Clearly BibDesk does
> something neat to encode and decode that field, but once created, the OS
> nor Finder know anything about that line or the file containing it. I
> don't think Finder would need to know about a string in an Org file
> either.

We can look at a BibDesk file to see how it works.  It adds a special field like:

	Bdsk-File-1 = {YnBsaXN0MDDUA...AAAAAAAAAAAAAAAMO}

We guess that this base64 encoded, so we decode it (M-x base64-decode-region)  This then gives us a binary plist (it starts with bplist) which we can turn into a readable form with M-: plutil -convert xml1 -o - - RET

This gives an xml representation of what BibDesk stores.  It’s an archived object of some kind, but I don’t know about OS X aliases to know what is the important part--I presume the NS.data portion.  It probably wouldn’t be too hard to borrow the code from BibDesk and extend Emacs to do the same thing, or write an external script.  I’m not sure whether it would be possible to do it without touching C/Obj-C.  I would be interested in using such a thing (in BibDesk .bib files actually), though probably not in writing it.  :-)

-Ivan

Re: Fwd: Mac OS Alias file links

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2829 bytes --]

On Mon, 14 Apr 2014, Ivan Andrus wrote:

> On Apr 14, 2014, at 12:36 PM, Ken Mankoff <mankoff@gmail.com> wrote:
>
>> On 2014-04-14 at 13:42, Charles Berry wrote:
>>
>>> For this to work as you fantasize, you would need to enable the Finder
>>> application to modify the part of the *.org file that encodes the
>>> alias when you change the location of the aliased file just as the
>>> Finder does to the alias when the location of the aliased file is
>>> modified in the Finder.
>>
>> I don't think so. I'm not sure how BibDesk handles it, but my BibTeX
>> file is not modified when I move the PDF that is linked to an entry via
>> that 1200 character field that encodes the alias. Clearly BibDesk does
>> something neat to encode and decode that field, but once created, the OS
>> nor Finder know anything about that line or the file containing it. I
>> don't think Finder would need to know about a string in an Org file
>> either.
>
> We can look at a BibDesk file to see how it works.  It adds a special field like:
>
> 	Bdsk-File-1 = {YnBsaXN0MDDUA...AAAAAAAAAAAAAAAMO}
>

> We guess that this base64 encoded, so we decode it (M-x 
> base64-decode-region)  This then gives us a binary plist (it starts with 
> bplist) which we can turn into a readable form with M-: plutil -convert 
> xml1 -o - - RET

Or copy it and run

pbpaste | base64 -D | plutil -p -

in the shell.

>
> This gives an xml representation of what BibDesk stores.

BibDesk has an archive of entries typically stored at

~/Library/Caches/Metadata/edu.ucsd.cs.mmccrack.bibdesk/*.bdskcache

and the 'NS.data' element of Bdsk-File-1 seems to point to one element.

The *.bdskcache file has a bplist and I guess the 'FileAlias' component 
is what points to the pdf or whatever.

The relevant source for the alias itself seems to be here:

http://sourceforge.net/p/bibdesk/svn/19370/tree//trunk/bibdesk/BDSKAlias.m

but I do not do objective C nor CoreFoundation.h, which I think is where 
the alias stuff lives now.

I think it would be necessary for one to have a good handle on 
the stuff in CoreFoundation.h to make sense of this.

> It’s an 
> archived object of some kind, but I don’t know about OS X aliases to 
> know what is the important part--I presume the NS.data portion.  It 
> probably wouldn’t be too hard to borrow the code from BibDesk and extend 
> Emacs to do the same thing, or write an external script.  I’m not sure 
> whether it would be possible to do it without touching C/Obj-C.  I would 
> be interested in using such a thing (in BibDesk .bib files actually), 
> though probably not in writing it.  :-)
>


One approach that sidesteps having to know the CoreFoundation.h stuff is 
to use the BibDesk AppleScript capabilities. There is a model for this at

http://www.jonathansick.ca/adsbibdesk/

written in python, FWIW.

HTH,

Chuck

Re: Fwd: Mac OS Alias file links

[Ken Mankoff]

On 2014-04-14 at 20:21, Charles C. Berry wrote:
> BibDesk has an archive of entries typically stored at
>
> ~/Library/Caches/Metadata/edu.ucsd.cs.mmccrack.bibdesk/*.bdskcache
>
> and the 'NS.data' element of Bdsk-File-1 seems to point to one element.
>
> The *.bdskcache file has a bplist and I guess the 'FileAlias' component 
> is what points to the pdf or whatever.

Aha! I think this is essentially what you described in your last
email when you said,

>> OTOH, writing an AppleScript to make an alias in a folder that is
>> never  moved, writing elisp to call that script and then make an
>> org-mode link to  the alias just created might work for you.  

I guess that is how it is done. I think I can figure out how to do this
much in elisp + a system language. The elisp side will be a good
learning project.

> One approach that sidesteps having to know the CoreFoundation.h stuff
> is to use the BibDesk AppleScript capabilities. There is a model for
> this at
>
> http://www.jonathansick.ca/adsbibdesk/
>
> written in python, FWIW.

Yes. The AppKit module is a nice interface from Python to the OSX
system. I think I will likely write the non-emacs code using this, or
AppleScript or Automator directly.

  -k.