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: Obscure error/warning/information message from git pull Date: Fri, 14 Nov 2014 23:35:35 +0200 Message-ID: <83d28ph3dk.fsf@gnu.org> References: <20141114120604.GA3859@acm.acm> <87a93topxv.fsf@igel.home> <83h9y1j18p.fsf@gnu.org> <87r3x590k0.fsf@maru2.md5i.com> <83tx21hf2f.fsf@gnu.org> <87tx21o50i.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1416000981 18699 80.91.229.3 (14 Nov 2014 21:36:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Nov 2014 21:36:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 14 22:36:14 2014 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 1XpOXO-0007u6-ED for ged-emacs-devel@m.gmane.org; Fri, 14 Nov 2014 22:36:14 +0100 Original-Received: from localhost ([::1]:37951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpOXO-0003js-23 for ged-emacs-devel@m.gmane.org; Fri, 14 Nov 2014 16:36:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpOXF-00034Y-V6 for emacs-devel@gnu.org; Fri, 14 Nov 2014 16:36:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpOXA-0008S9-23 for emacs-devel@gnu.org; Fri, 14 Nov 2014 16:36:05 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:39692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpOX3-0008RX-IN; Fri, 14 Nov 2014 16:35:53 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NF100N00S6JL400@mtaout25.012.net.il>; Fri, 14 Nov 2014 23:31:28 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NF100N13T4GE830@mtaout25.012.net.il>; Fri, 14 Nov 2014 23:31:28 +0200 (IST) In-reply-to: <87tx21o50i.fsf@fencepost.gnu.org> 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.181 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:177127 Archived-At: > From: David Kastrup > Date: Fri, 14 Nov 2014 22:18:21 +0100 > > Eli Zaretskii writes: > > > I wasn't asking about Windows. It is clear to me by reading the > > script that using that on Windows is a bad idea, because symlinks are > > (a) only supported since Vista, and (b) require to run the script "As > > Administrator". (And then there's a known caveat of removing the > > symlinked directory that actually removes the target, if you aren't > > careful to use rmdir.) > > It's things like this that make me wonder whether the system programmers > at Microsoft are forbidden from using any other operating system. > > How would anyone with modest exposure to decent operating systems stand > this kind of thing? > > As programmer I somewhat regularly encounter the situation "this > behavior is far too inconsistent to make it worth documenting: let's > rather work on fixing it first". It usually does not even need the > comparison to other systems to figure out the bad stuff from the good. > > Now I can understand that at some times commercial development results > in decisions like "we won't invest work on implementing this". But > "we'll invest into creating a quite crippled and mostly useless version > of the feature": where is the point in that? > > How does this work? Somebody knowing the feature from other system pins > down the salient points on a piece of scrap paper, someone else who > never saw it and speaks a different language then writes the spec sheet, > and somebody else who never saw the point in that feature implements > those parts of that spec sheet that are easiest to do? Not sure what you are steaming about. If that's the fact that creating symlinks requires privileges, then the rationale is that a suitably pointed symlink can be used to circumvent security permissions. I'm not a security expert, so I don't know whether this argument holds water. If you are talking about the accidental removal, then using "DEL" (the equivalent of the Unix 'rm') to remove a symlink to a directory is actually a Unix-ism brought to Windows, because on Windows a symlink to a directory is treated as a directory, and has the directory mode bit set. For any directory X, "DEL X" always meant "remove all files in X" on Windows. Therefore, doing that with a symlink to a directory simply behaves like DEL always behaved. The culprit is the Unix semantics molded on the muscle memory of those who type such commands on Windows. > Something must be going seriously wrong somewhere, and it's not the > first time that I cannot fathom just what. A very pertinent observation in a discussion about Git.