Message-ID: <37CA60C3.B70FB929@softhome.net>
Date: Mon, 30 Aug 1999 12:45:23 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: symlink() & is_v2_prog() question
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990830120057 DOT 12471C-100000 AT is>
Content-Type: text/plain; charset=iso-8859-4
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Mon, 30 Aug 1999, Laurynas Biveinis wrote:
> 
> >  - new library function readlink() and its docs, taken from glibc-2.1.1.
> >    In fact, glibc-2.1.1 manual is my single source of info about symlinks.
> 
> Beware: glibc is under LGPL, so looking too hard inside it might get you
> in legal trouble with your sources and the docs.

Well, I didn't copy them word-by-word. I just looked at docs, how readlink()
should behave. I even haven't seen readlink() code in glibc().

> I assume you want this to get into libc.a some day.  If so, I would like

Sure.

> once again to suggest that we discuss the various implications of this
> feature before you invest too much effort (unless you don't mind wasting
> it; most people do).  I'm still wondering what benefits symlinks will
> bring that justify such a thorough rewrite of core library functions.

Eli, haven't you faced the same question when you wrote stat()?
And about the changes - they're in many places, but they're small.

To be honest, they can increase for symlinks to directories, when I
have to support following case - open("c:/symlink/dir/file.c").
                                          ^^^^^^^ 

> For example, what would we lose if we simply augment `symlink' with code
> that calls `link' if the target is not a DJGPP executable?  The effect is
> the same (albeit with some disk space wasted), but it's much less hassle

How much is "some"? Example - I've built Turbo Vision several times with 
different options, so I have librhtv-small.a, librhtv-mss.a, librhtv-debug.a. 
One of them is renamed to librhtv.a, that's what I use by default. Of course, 
I would use symlinks, but implementing them by copying would waste 7 MB of 
disk space. And symlinking directories that way would be times bigger waste 
of disk space.

Going further, imagine if someone implements shared libraries for DJGPP
with version numbers in file names... On Linux this way would waste hundreds
of mbytes.

> to implement and it doesn't rock the boat so much.

Doesn't it break assumption that that changes through symlink affect real
file? I don't think we can skip this issue so easily. And how will work 
symlinks to directories in such case? Files in them should be copied as well.

> What about `remove' and `rename'?  Don't they have any effect on
> symlinks.

No. they work on symlink files themselves. Imagine, how one could delete
symlink, if they don't work this way.

Laurynas Biveinis