From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Windows junctions Date: Thu, 19 Feb 2015 10:50:10 +0200 Message-ID: <83ioey475p.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1424335829 15994 80.91.229.3 (19 Feb 2015 08:50:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Feb 2015 08:50:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Fabrice Popineau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 19 09:50:19 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YOMoM-0004SM-Fd for ged-emacs-devel@m.gmane.org; Thu, 19 Feb 2015 09:50:18 +0100 Original-Received: from localhost ([::1]:55348 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOMoL-0005kH-Sm for ged-emacs-devel@m.gmane.org; Thu, 19 Feb 2015 03:50:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOMo5-0005k2-Eh for emacs-devel@gnu.org; Thu, 19 Feb 2015 03:50:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOMo2-0002By-5Y for emacs-devel@gnu.org; Thu, 19 Feb 2015 03:50:01 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:42809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOMo1-0002Bg-TV for emacs-devel@gnu.org; Thu, 19 Feb 2015 03:49:58 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NK000300GGXT500@mtaout26.012.net.il> for emacs-devel@gnu.org; Thu, 19 Feb 2015 10:50:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NK0003QUGJPNK00@mtaout26.012.net.il>; Thu, 19 Feb 2015 10:50:13 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183284 Archived-At: > From: Fabrice Popineau > Date: Wed, 18 Feb 2015 14:09:52 +0000 (UTC) > > This question has been asked on Stackexchange: > > http://emacs.stackexchange.com/questions/6070/hard-and-soft-links-junctions-under-windows > > How difficult would it be to report junctions as symlinks? > I find it desirable and informative. > > Moreover, all the support seems to be already there. > Specifically, it would suffice to handle the case of > IO_REPARSE_TAG_MOUNT_POINT in src/w32.c/is_symlink() > and src/w32.c/readlink() the same way it is done for > IO_REPARSE_TAG_SYMLINK. Junction points are more like hard links to directories than like symlinks, although deleting the target of a junction leaves the junction pointing nowhere, which is more like a symlink. But other features are more like hard links: they actually share the data with the target, and don't require UAC elevation to create them. Also, symlinks are not supported before Vista, so having only symlinks to directories on those systems would be confusing, I think. So IMO treating junction points as symlinks would be wrong due to a different semantics and feature set. We could perhaps treat junction points as hard links to directories (since the "normal" hard links don't support directories on NTFS). So perhaps changing sys_link to create a junction point when the target is a directory, provided that the nlinks member of the list returned by file-attributes will indeed reflect that it's a hard link (currently, we return it as 1, i.e. some special code for junctions should be added to our implementation of 'stat'). That said, I'm not sure I see any important use cases for adding this functionality, so perhaps I'm missing something.