This is the mail archive of the
mailing list for the Cygwin project.
Re: bug: hard links to soft links do not work
> * In message <20020801210148.GB29167@redhat.com>
> * On the subject of "Re: bug: hard links to soft links do not work"
> * Sent on Thu, 1 Aug 2002 17:01:48 -0400
> * Honorable Christopher Faylor <email@example.com> writes:
> On Thu, Aug 01, 2002 at 04:21:43PM -0400, Sam Steingold wrote:
> >actually, this is very easy:
> >(defmethod hard-link :around (from to)
> > (if (symbolic-link-p to)
> > (symbolic-link from (resolve-symbolic-link to))
> > (call-next-method)))
> >i.e., when the target is a symlink, you symlink to its target.
> Is that *lisp* code? This makes it easy because...? I don't quite
> follow. Obviously anyone can conceive of some logic to make this fail
> but without looking at the actual code in question it isn't going to
> be too useful.
the above is indeed CLOS code of how link() should actually be
implemented in the cygwin libc.
> Just to make it clear again, this is a cygwin dll problem. Modifying
> ln fixes ln. It doesn't fix perl or python or any C program that uses
yes it will!
> >think of a symlink as if it had no inode (like it is on a real FS),
> >i.e., just a special dirent pointing to the target.
> >Then the hardlink of a symlink is another symlink pointing to the same
> >place, since the nature of hardlink is to create a file which is
> >indistinguishable from the target.
int link(const char *oldpath, const char *newpath);
let me repeat:
when oldpath is a symbolic link,
newpath should be a symbolic link too!
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
C combines the power of assembler with the portability of assembler.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html