From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: w32.c/link() Date: Mon, 16 Jun 2014 19:55:25 +0200 Message-ID: References: <83k38gvr8k.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3224684ef4d04fbf7bc08 X-Trace: ger.gmane.org 1402941361 24198 80.91.229.3 (16 Jun 2014 17:56:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Jun 2014 17:56:01 +0000 (UTC) Cc: Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 16 19:55:54 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 1Wwb8M-0001Pc-Ae for ged-emacs-devel@m.gmane.org; Mon, 16 Jun 2014 19:55:54 +0200 Original-Received: from localhost ([::1]:45777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwb8L-0000K6-Er for ged-emacs-devel@m.gmane.org; Mon, 16 Jun 2014 13:55:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwb8H-0000Jx-Qr for emacs-devel@gnu.org; Mon, 16 Jun 2014 13:55:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wwb8G-0000Rt-KY for emacs-devel@gnu.org; Mon, 16 Jun 2014 13:55:49 -0400 Original-Received: from mail-oa0-x233.google.com ([2607:f8b0:4003:c02::233]:62258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwb8E-0000Qa-Ev; Mon, 16 Jun 2014 13:55:46 -0400 Original-Received: by mail-oa0-f51.google.com with SMTP id j17so6199887oag.38 for ; Mon, 16 Jun 2014 10:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jyGfY/A04qsw1ojd9FdgNEMdgW1uYb+0OepNWHA5b6c=; b=j/Uf3/4G82x5EHVc3s8zCXAWP9MpvXIgyjLED4q6sKULU5N+1KGd5QXMYeqTRjTlvK 9ELhaMXtBiDO+0N9EkHpPMRyx0EMeMjv/pyT4fEAfaYUSqOO+9I3Fgu1Merbafx2K/U+ OqQ2UpjirwJJVH2CrIbt0KfVfxE6IbUZfyTtCQhPf7rN1mp+PS/VWYYdaz2YIKQ2FTHN d4aKExCqIZ9n4G6wLb0hX8doEUUxXBZsMfaguR7nXb4JZc/jvkz6uAQ2Pc55Z0AcGBQV TvYMGUFtzwfjaDA+unsiT0cVwYqN01LATUAWikk1BNpJX3EzRdMuyuphpTXqcArdI3QV LmoQ== X-Received: by 10.182.246.40 with SMTP id xt8mr3867549obc.76.1402941345162; Mon, 16 Jun 2014 10:55:45 -0700 (PDT) Original-Received: by 10.202.2.207 with HTTP; Mon, 16 Jun 2014 10:55:25 -0700 (PDT) In-Reply-To: <83k38gvr8k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::233 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:172478 Archived-At: --001a11c3224684ef4d04fbf7bc08 Content-Type: text/plain; charset=UTF-8 Thanks for the explanations. After carefully trying again, it is working as expected. Fabrice 2014-06-16 16:55 GMT+02:00 Eli Zaretskii : > > From: Fabrice Popineau > > Date: Mon, 16 Jun 2014 07:30:50 +0000 (UTC) > > > > I tried to use add-name-to-file from elisp, > > which calls w32.c/link(). It seems to end up in doing > > a copy of the file. > > No, it doesn't copy. It creates a hard link, as you'd expect. > > You can verify this yourself, with the following simple procedure: > > . start Dired on some directory > . go to any file in the listing (not a directory: Windows doesn't > support hard links to directories) > . notice that the second column from the left says "1", i.e. this > file has only 1 link to its data > . press H, type the name of a link in the minibuffer and press RET > . press g to refresh the directory listing, and notice that both the > original file and the link now have their link count at 2 > . visit the original file, set backup-by-copying-when-linked to a > non-nil value, then modify the file and save it > . visit the link and observe that the same modifications are > "miraculously" present there as well > . still not convinced? type "C-u C-x d", change the switches to say > "-ali", hit RET, and observe that both the file and the link have > the same filesystem index (a.k.a. "inode"), which means they share > the same file data > > If you have a decent port of GNU 'ls', you will see the link counts > change there as well. > > If you see something different from the above, please describe what > you see. > > > I'm fine with that, but that wasn't clear before trying it. > > OTOH if hard links were possible, why not using them? Permissions? > > We do use them (on NTFS; on other Windows filesystems you'll likely > get an error). > > > Could someone (Eli ?) care to explain why link() is implemented this way? > > Why BackupWrite() is used? I would have expected either CopyFile() or > > CreateHardLink(). > > CreateHardLink was introduced with Windows 2000, while this code tries > to support older NT systems which lacked that API. Back then this was > the only way to create a hard link. I don't think we still support > NT4 etc., but the code works very well, so I see no reason to rewrite > it using newer APIs. > --001a11c3224684ef4d04fbf7bc08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the explanations.
After carefully trying ag= ain, it is working as expected.

Fabrice


2014-06-16 1= 6:55 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:
> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 16 Jun 2014 07:30:50 +0000 (UTC)
>
> I tried to use add-name-to-file from elisp,
> which calls w32.c/link(). It seems to end up in doing
> a copy of the file.

No, it doesn't copy. =C2=A0It creates a hard link, as you'd expect.=

You can verify this yourself, with the following simple procedure:

=C2=A0 . start Dired on some directory
=C2=A0 . go to any file in the listing (not a directory: Windows doesn'= t
=C2=A0 =C2=A0 support hard links to directories)
=C2=A0 . notice that the second column from the left says "1", i.= e. this
=C2=A0 =C2=A0 file has only 1 link to its data
=C2=A0 . press H, type the name of a link in the minibuffer and press RET =C2=A0 . press g to refresh the directory listing, and notice that both the=
=C2=A0 =C2=A0 original file and the link now have their link count at 2
=C2=A0 . visit the original file, set backup-by-copying-when-linked to a =C2=A0 =C2=A0 non-nil value, then modify the file and save it
=C2=A0 . visit the link and observe that the same modifications are
=C2=A0 =C2=A0 "miraculously" present there as well
=C2=A0 . still not convinced? type "C-u C-x d", change the switch= es to say
=C2=A0 =C2=A0 "-ali", hit RET, and observe that both the file and= the link have
=C2=A0 =C2=A0 the same filesystem index (a.k.a. "inode"), which m= eans they share
=C2=A0 =C2=A0 the same file data

If you have a decent port of GNU 'ls', you will see the link counts=
change there as well.

If you see something different from the above, please describe what
you see.

> I'm fine with that, but that wasn't clear before trying it. > OTOH if hard links were possible, why not using them? Permissions?

We do use them (on NTFS; on other Windows filesystems you'll likely
get an error).

> Could someone (Eli ?) care to explain why link() is implemented this w= ay?
> Why BackupWrite() is used? I would have expected either CopyFile() or<= br> > CreateHardLink().

CreateHardLink was introduced with Windows 2000, while this code tries
to support older NT systems which lacked that API. =C2=A0Back then this was=
the only way to create a hard link. =C2=A0I don't think we still suppor= t
NT4 etc., but the code works very well, so I see no reason to rewrite
it using newer APIs.

--001a11c3224684ef4d04fbf7bc08--