Date: Mon, 30 Aug 1999 14:19:13 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Laurynas Biveinis cc: DJGPP Workers Subject: Re: symlink() & is_v2_prog() question In-Reply-To: <37CA60C3.B70FB929@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.