Message-ID: <37CA7A1F.B5219B90@softhome.net>
Date: Mon, 30 Aug 1999 14:33:35 +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 990830135529 DOT 17308D-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:
> > > 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

Here is my personal problem - I feel better when I talk about something
real, because in other case I'm afraid to talk about things that are
beyond my ability to code...

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

I think symlinks would make porting GCC easier, well, Andris knows better,
but in readme.DJGPP for gcc-2.95.1 it is said:

   in such parts Win95 DPMI server can take. Second reason was to
   simulate bootstraping gcc which was impossible in other way due to
   absence of fully functional symbolic links.

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

What will be after 2.03, 2.04 or 2.1? Symlinks would be OK for 2.1, and
there will be enough time for testing their stableness.

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

OK, a technical question - I have character string (symlink file prefix)
which is used in two source files. Should I put it in <unistd.h> as
_DJGPP_SYMLINK_PREFIX or create internal include file, just like xstat.h? 

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

Symlinks do not replace files - they help to organize them, at least for me.
If they are available, I would use them, but if they copy files, many
MBytes will be wasted in my case.

> If disk space is such a huge problem, people could use DBLSPACE.  I

Don't laugh, but I had 20 MBytes hard disk on a 286 a year ago... And
it was drivespaced.

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

How about that utility which created symlink? If programmer uses symlink()
instead of some file copy routine, then he/she may expect something.

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

OK, another example from real life (my hard disk): I have directories
c:/djgpp/contrib/tvision.1.0.7, which contains latest official TVision 
version and c:/djgpp/contrib/tvision.my, which has my changes, bugfixes, etc.
But gcc won't find Turbo Vision, unless I have dir c:/djgpp/contrib/tvision.
Again symlinks would be useful here.

Laurynas Biveinis