This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug: hard links to soft links do not work

> * In message <>
> * 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 <> 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
> link().

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 ( running RedHat7.3 GNU/Linux
<> <> <>
<> <>
C combines the power of assembler with the portability of assembler.

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]