delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/08/24/09:36:25

Message-ID: <39A5266F.2C931D88@softhome.net>
Date: Thu, 24 Aug 2000 15:43:11 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Symlink resolving rewrite
Reply-To: djgpp-workers AT delorie DOT com

If readlink() has to resolve symlinks, then whole thing
needs to be rewritten, otherwise it will be highly ineffective.

Here is my "design paper" for the new way; please tell me
about any brain damages here before I start writing the code.
There are three functions for that, just like now: readlink(),
__solve_dir_symlinks() and __solve_symlinks().

1) readlink():
   Calls __solve_dir_symlinks(), then tries to read symlink
destination, if any, from returned path. 

2) __solve_dir_symlinks():

With this example path:
c:/dir/link/dir2
   Saves last path part (dir2 in example), also saves everything
before second slash from the end (c:/dir/) calls readlink() for
c:/dir/link. If readlink returns relative path, then it is appended
to saved c:/dir/, if absolute, then saved 'c:/dir/' is discarded.
Finally last path part ('dir2') is appended to result.

3) __solve_symlinks():
  Calls __solve_dir_symlinks(), saves result without last path
component, then calls readlink() for the whole returned path,
if it returns relative path - append to what've saved, if absolute -
return it.

As you can see, there is still some duplicated code between 
__solve_dir_symlinks(), and __solve_symlinks(). However, I couldn't
think of anything better than this recursive approach.

If anything is unclear, just ask.
Comments welcome,
Laurynas

- Raw text -


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