Mail Archives: djgpp-workers/1999/08/30/09:17:16
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 -