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 20:48:14 +0200 Message-ID: References: <83k38gvr8k.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01176ac575bfd704fbf8797f X-Trace: ger.gmane.org 1402944533 30494 80.91.229.3 (16 Jun 2014 18:48:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Jun 2014 18:48:53 +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 20:48:46 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 1WwbxV-0004SB-5v for ged-emacs-devel@m.gmane.org; Mon, 16 Jun 2014 20:48:45 +0200 Original-Received: from localhost ([::1]:45953 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwbxU-0006la-IL for ged-emacs-devel@m.gmane.org; Mon, 16 Jun 2014 14:48:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwbxP-0006lV-B1 for emacs-devel@gnu.org; Mon, 16 Jun 2014 14:48:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WwbxO-0002zH-1h for emacs-devel@gnu.org; Mon, 16 Jun 2014 14:48:39 -0400 Original-Received: from mail-ob0-x22e.google.com ([2607:f8b0:4003:c01::22e]:58968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwbxM-0002uO-1h; Mon, 16 Jun 2014 14:48:36 -0400 Original-Received: by mail-ob0-f174.google.com with SMTP id va2so6241602obc.33 for ; Mon, 16 Jun 2014 11:48:35 -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=lCzzEfOyeWx3a8cmmX2L36irqreJCi9A6vybOnFlmvc=; b=EKJvQtoFhvxsDurRBSL2ISOyhMYARHGydANlALVAwEgJZpnfiGYt0Xk/DP6hdC16Q2 E7W+K2h3myd3gm+3Em2dFgLr1Zt23fHTIK1sRsK4r+yp3LY5oaVUzBZahCLRiurbOn6l oZhIa4zkUVYI8PbkjvRouCD0rkGpw0mWWEuwp+EMLAjlxNrJWgZvmW8egIMTjBM5Q6fS XOKiYeGNiNoMqyjEaEIAyv1jXCewwu/N/AGFIqVy45thZHM/9i/pLNkCaA/jZkZZNmzr o5DZVORH9oMZs7gEFE2Z1mty0FsGLEwaBJC/Z5mDixaqDAxB/W5jwxSr5h1HDg1qa8Wq A0Cg== X-Received: by 10.60.178.243 with SMTP id db19mr21625129oec.11.1402944515061; Mon, 16 Jun 2014 11:48:35 -0700 (PDT) Original-Received: by 10.202.2.207 with HTTP; Mon, 16 Jun 2014 11:48:14 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::22e 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:172481 Archived-At: --089e01176ac575bfd704fbf8797f Content-Type: text/plain; charset=UTF-8 I have found my problem. I did what Eli said and it is working as expected. But now I start again : emacs -Q M-: (add-name-to-file "c:/temp/foo.el" "c:/temp/foo1.el" t) M-x c:/temp/foo.el add a few characters C-x s M-x dired And foo.el size has changed, but not foo1.el size. This is because after editing foo.el, foo1.el is still a hard link but to foo.el~ (autosave file). :-/ Quite misleading! Sorry for the noise. Fabrice 2014-06-16 19:55 GMT+02:00 Fabrice Popineau : > 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. >> > > --089e01176ac575bfd704fbf8797f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have found my problem.

I d= id what Eli said and it is working as expected.
But now I sta= rt again :

emacs -Q

M-: (= add-name-to-file "c:/temp/foo.el" "c:/temp/foo1.el" t)<= /div>

M-x c:/temp/foo.el
add a few characters
=
C-x s
M-x dired

And foo.el size has= changed, but not foo1.el size.

This is because af= ter editing foo.el, foo1.el is still a hard link but to foo.el~ (autosave f= ile). :-/
Quite misleading! Sorry for the noise.

Fabric= e



<= br>
2014-06-16 19:55 GMT+02:00 Fabrice Popineau <= span dir=3D"ltr"><fabrice.popineau@gmail.com>:
Thanks for the explanations= .
After carefully trying again, it is working as expected.
Fabrice


2014-06-16 16: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.


--089e01176ac575bfd704fbf8797f--