www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/08/30/09:17:16

Date: Mon, 30 Aug 1999 14:19:13 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Laurynas Biveinis <lauras AT softhome DOT net>
cc: DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: symlink() & is_v2_prog() question
In-Reply-To: <37CA60C3.B70FB929@softhome.net>
Message-ID: <Pine.SUN.3.91.990830135529.17308D-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 30 Aug 1999, Laurynas Biveinis wrote:

> > 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()?

Sure I did!

But `stat' design was discussed for about a month before I even wrote a 
single code line.  And the benefit was that all the GNU programs that 
looked at st_ino would port without any special code.  I cannot imagine 
how all the ports made since then would have been possible if it were 
not for `stat'.  In contrast, here we are mainly talking about disk 
space savings, or so it seems.

Also, `stat' needed a lot of changes and improvements before we got it 
right.  But while `stat' was introduced together with DJGPP v2.0, which 
was new and therefore was supposed to have grave bugs, we are now in 
v2.03, where core functionality is supposed to be stable.

> And about the changes - they're in many places, but they're small.

The "many places" part is what scares me.  A single localized change is 
much easier to maintain and fix than a large number of small ones.

But let's put this aside for a while and first agree that the feature is 
worth the effort.  If it is, then I'm sure the technical problems will
be solved.

> 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.

You are talking as if half of the files on our disks could have been 
replaced with symlinks.  I don't think this is true.

If disk space is such a huge problem, people could use DBLSPACE.  I 
though that the fact that nobody uses it is *the* proof that disk space 
isn't a problem after all.

> > to implement and it doesn't rock the boat so much.
> 
> Doesn't it break assumption that that changes through symlink affect real
> file?

No, because the simulate-symlink-by-copying approach only implements one 
half of the symlink.  It does NOT introduce the symlink file type into 
the S_IF* macros.  Since no file is a link, no utility will expect the 
target of the link to change.

> 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.

If it is required.  Symlinks to directories are used for administrative 
needs (at least in my excperience), which is less important on a PC.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019