Windows Emacs doesn't understand UNIX symbolic link?
Yang
I recently installed emacs on 32bit Windows Vista home premium. I mainly
use it to access/edit source code on a remote UNIX machine (through the
tramp 2.1.9 package). However one thing that bothers me is that the
windows emacs does not seem to undertand UNIX symbolic link.
For example, on the remote Unix machine, I have "a.cc", which is a normal
file; and also "asl.cc", which is a symbolic link to "a.cc", thus "asl.cc
-> a.cc".
If I use my windows emacs to access "asl.cc", it can read it correctly.
However once you made any changes and save it, things became messed up.
"a.cc" didn't get updated, instead you have this:
"asl.cc" becomes a normal file and no longer points to "a.cc"
"asl.cc~" now is a symbolic link and points to "a.cc"
"a.cc" is not changed.
The current available versions of precompiled windows emacs at:
ftp://ftp.gnu.org/gnu/emacs/windows/ all seem to have this problem.
Anyone know what was going on and how to fix this? or could this be a
problem with the tramp package?
Thanks a lot!!
--Yang
William Xu
> Anyone know what was going on and how to fix this?
I've never used Windows Vista, so the following is my experience on
Windows XP, which probably also applies to Windows Vista.
On Windows XP, if you try to access some shared files/directories from a
*nix machine, since Windows XP doesn't understand *nix symbolic links,
all symbolic links will simply become a copy of the original file,
nothing more. My advice is: never edit *nix symbolic links on Windows
XP.
--
William
Yang
used to use carbon emacs on a mac and that works fine with UNIX file
systems. I like the looks and fonts of the carbon emacs. Now I also like
the emacs looks and font rendering on vista. Is there any patch around to
let the windows emacs understand UNIX symbolic links? I know there used to
be a package for emacs to understand windows file shortcuts.
William Xu
> Thanks for sharing the experience. That is a sad news if this is
> true.
I used to suffer a lot sharing a svn repo containing symbolic links.
> I used to use carbon emacs on a mac and that works fine with UNIX file
> systems.
Yes, Mac OS X supports symbolic links well.
> I like the looks and fonts of the carbon emacs. Now I also like
> the emacs looks and font rendering on vista. Is there any patch around
> to let the windows emacs understand UNIX symbolic links?
It sounds more like a system level problem to me, not specific to emacs.
I did a google and find this:
http://www.pearlmagik.com/winbolic/
I've not tried it myself, but maybe helpful for you.
--
William
Yang
look later. I also did fair amount of search on google, looks like it is
very difficult for Windows to follow Unix symbolic links (for various
reasons).
I guess at the mean time I'll just stick with the current emacs on vista
and avoid opening any symbolic links on the remote unix machine.
On Wed, 2 Apr 2008, William Xu wrote:
Eli Zaretskii
> Date: Tue, 1 Apr 2008 11:54:35 -0500
>
> Is there any patch around to let the windows emacs understand UNIX
> symbolic links?
Not that I know of, and neither can I imagine how an Emacs patch could
cure a malady of the operating system: for symlinks to work on
Windows, the Windows filesystem needs to do something sensible with
symlinks, because even if the symlink is on a Unix disk, Emacs
accesses it through Windows file I/O APIs, and those simply don't
support symlinks.
It is true that Vista introduced some kind of native symlinks, but
from what I hear, their semantics is quite different from Posix
symlinks, and in any case, the OS layer that mounts the Unix volume
should map Unix symlinks to Vista symlinks before Emacs could make use
of them.
> I know there used to be a package for emacs to understand windows
> file shortcuts.
Windows shortcuts are native Windows feature, which is different.
Barry Margolin
Eli Zaretskii <el...@gnu.org> wrote:
> > From: Yang <fz...@HPC.MsState.Edu>
> > Date: Tue, 1 Apr 2008 11:54:35 -0500
> >
> > Is there any patch around to let the windows emacs understand UNIX
> > symbolic links?
>
> Not that I know of, and neither can I imagine how an Emacs patch could
> cure a malady of the operating system: for symlinks to work on
> Windows, the Windows filesystem needs to do something sensible with
> symlinks, because even if the symlink is on a Unix disk, Emacs
> accesses it through Windows file I/O APIs, and those simply don't
> support symlinks.
Did you forget that he said he's using TRAMP, not the Windows filesystem
API?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Michael Albinus
> In article <mailman.9824.120711643...@gnu.org>,
> Eli Zaretskii <el...@gnu.org> wrote:
>
>> > From: Yang <fz...@HPC.MsState.Edu>
>> > Date: Tue, 1 Apr 2008 11:54:35 -0500
>> >
>> > Is there any patch around to let the windows emacs understand UNIX
>> > symbolic links?
>>
>> Not that I know of, and neither can I imagine how an Emacs patch could
>> cure a malady of the operating system: for symlinks to work on
>> Windows, the Windows filesystem needs to do something sensible with
>> symlinks, because even if the symlink is on a Unix disk, Emacs
>> accesses it through Windows file I/O APIs, and those simply don't
>> support symlinks.
>
> Did you forget that he said he's using TRAMP, not the Windows filesystem
> API?
The problem is not Tramp in this case. If I try to create a symbolic
link in a remote directory, I get the error
(void-function make-symbolic-link)
And indeed, this function does not exist for W32 systems; see the
check in fileio.c:
#ifdef S_IFLNK
DEFUN ("make-symbolic-link", Fmake_symbolic_link, Smake_symbolic_link, 2, 3,
...
Eli: do you see a chance to enable that function for W32 systems? It
should first check for a file name handler (as it does now), and
_then_ check whether the native functionality can be used.
A rude workaround would be
(defalias 'make-symbolic-link 'tramp-handle-make-symbolic-link)
But it is dangerous; because it fails on non-remote directories.
Best regards, Michael.
Eli Zaretskii
> Date: Wed, 02 Apr 2008 02:33:44 -0400
>
> Did you forget that he said he's using TRAMP, not the Windows filesystem
> API?
Yes, I failed to notice that, sorry.
In that case, I guess a bug report or a feature request to the Tramp
maintainer would be in order.
Eli Zaretskii
> Date: Wed, 02 Apr 2008 09:50:43 +0200
>
> The problem is not Tramp in this case. If I try to create a symbolic
> link in a remote directory, I get the error
>
> (void-function make-symbolic-link)
>
> And indeed, this function does not exist for W32 systems; see the
> check in fileio.c:
>
> #ifdef S_IFLNK
> DEFUN ("make-symbolic-link", Fmake_symbolic_link, Smake_symbolic_link, 2, 3,
> ...
>
> Eli: do you see a chance to enable that function for W32 systems? It
> should first check for a file name handler (as it does now), and
> _then_ check whether the native functionality can be used.
Yes, that's what we need: to change make-symbolic-link so that only
its native part is ifdef'ed away on systems without S_IFLNK, and the
file-handler part is available on all systems.
Peter Dyballa
Am 02.04.2008 um 19:09 schrieb Eli Zaretskii:
>> From: Barry Margolin
>> Date: Wed, 02 Apr 2008 02:33:44 -0400
>>
>> Did you forget that he said he's using TRAMP, not the Windows
>> filesystem
>> API?
>
>
Why should that make a difference? Although TRAMP sees on the remote
UNIX host a sym-link it can present to MS Losedos nothing but some
kind of file.
--
Greetings
Pete
Give a man a fish, and you've fed him for a day. Teach him to fish,
and you've depleted the lake.
Eli Zaretskii
> From: Peter Dyballa <Peter_...@Web.DE>
> Date: Wed, 2 Apr 2008 19:27:18 +0200
>
>
> >> Did you forget that he said he's using TRAMP, not the Windows
> >> filesystem
> >> API?
> >
> >
>
>
> Why should that make a difference? Although TRAMP sees on the remote
> UNIX host a sym-link it can present to MS Losedos nothing but some
> kind of file.
And what does Tramp present to Emacs on a Unix system? isn't that
``some kind of file'' as well?
Michael Albinus
> Why should that make a difference? Although TRAMP sees on the remote
> UNIX host a sym-link it can present to MS Losedos nothing but some
> kind of file.
Tramp is able to create symlinks, and to follow symlinks on remote UNIX
filesystems. I've checked it with the workaround I've mentioned the
other message, on a W32 machine.
> Greetings
>
> Pete
Best regards, Michael.
Peter Dyballa
Am 02.04.2008 um 19:54 schrieb Eli Zaretskii:
>> Why should that make a difference? Although TRAMP sees on the remote
>> UNIX host a sym-link it can present to MS Losedos nothing but some
>> kind of file.
>
> ``some kind of file'' as well?
A file with the character of a sym-link – and UNIX can handle that.
On a system that can't distinguish a file from a sym-link it will ask
to save the file's original contents it has read via the sym-link as
<sym-link>~ and will then ask to save the changed contents under the
name of <sym-link>. A system able to handle sym-links won't send such
requests to TRAMP, so TRAMP won't do the nonsense described.
--
Greetings
Pete
From error to error, one discovers the entire truth.
- Sigmund Freud
Jason Rumney
> Why should that make a difference? Although TRAMP sees on the remote
> UNIX host a sym-link it can present to MS Losedos nothing but some
> kind of file.
Tramp doesn't present anything to Windows. It presents things directly
to Emacs.
Eli Zaretskii
>
>
> Am 02.04.2008 um 19:54 schrieb Eli Zaretskii:
> >> UNIX host a sym-link it can present to MS Losedos nothing but some
> >> kind of file.
> >
> > ``some kind of file'' as well?
>
>
> A file with the character of a sym-link – and UNIX can handle that.
For remote files, Tramp handles that, not the local OS. If the remote
file is a symlink, I'd expect Tramp to resolve it and bring to Emacs
the contents of the target of the link.
> On a system that can't distinguish a file from a sym-link
For a remote file, it's Tramp that needs to distinguish between them.
The file-symlink-p primitive should hand the file name to Tramp, for
that to happen, as it probably does on Unix.
> A system able to handle sym-links won't send such requests to TRAMP,
> so TRAMP won't do the nonsense described.
Are you sure that Tramp does such nonsense on Unix?
Michael Albinus
> Yes, that's what we need: to change make-symbolic-link so that only
> its native part is ifdef'ed away on systems without S_IFLNK, and the
> file-handler part is available on all systems.
The appended patch (towards the trunk) shall do the job. I have no build
environment for W32; could somebody, please, test it there?
Best regards, Michael.