Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com To: cygdev Subject: Re: [RFD]: Using a new feature of Win2K for symlinks References: <394007B4 DOT FADA8798 AT vinschen DOT de> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Kazuhiro Fujieda Date: 09 Jun 2000 14:33:48 +0900 In-Reply-To: Corinna Vinschen's message of Thu, 08 Jun 2000 22:53:08 +0200 Message-ID: Lines: 25 X-Mailer: Gnus v5.3/Emacs 19.34 >>> On Thu, 08 Jun 2000 22:53:08 +0200 >>> Corinna Vinschen said: > - The IO_REPARSE_TAG_SYMBOLIC_LINK is nice but completely useless > at the moment or on a base W2K system (I don't know exactly). I guess Microsoft will ship a file-system filter which recognize this tag along with Interix or SFU in the near feature. > Disadvantage: > > Reparse point symlinks are always absolute windows > paths. Relative paths are impossible. So that patch > always changes the incoming path to an absolute > windows path. Maybe, this will break some apps ?!? A windows path can't revert to the original posix path via conv_to_win32_path. So the mechanisms depending only on win32 paths can break some apps. For example, the current implementation of getcwd() breaks `du' and `find' executed in the directory `/usr'. I'm afraid your approach will cause this kind of problem. ____ | AIST Kazuhiro Fujieda | HOKURIKU School of Information Science o_/ 1990 Japan Advanced Institute of Science and Technology