w32.c/link()

w32.c/link()

[Fabrice Popineau]

Hi,

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

Could someone (Eli ?) care to explain why link() is implemented this way?
Why BackupWrite() is used? I would have expected either CopyFile() or 
CreateHardLink().

Fabrice

Re: w32.c/link()

[Eli Zaretskii]

> 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.  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.

Re: w32.c/link()

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

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.  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.
>

[-- Attachment #2: Type: text/html, Size: 3049 bytes --]

Re: w32.c/link()

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]

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 <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.  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.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4217 bytes --]

Re: w32.c/link()

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 16 Jun 2014 20:48:14 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> 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). :-/

That's why I told you to set backup-by-copying-when-linked to a
non-nil value: out avoids the problem you describe.  If you don't do
that, Emacs _renames_ the original file to the backup name, so the
linked file gets renamed, and the new one, created under its name, is
not a link.

Re: w32.c/link()

[Stefan Monnier]

> 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.

Try C-h f backup-by-copying TAB


        Stefan

Re: w32.c/link()

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

Thanks. Stupid of me to have been caught this way. I knew it, but never
used it so...



2014-06-16 22:58 GMT+02:00 Stefan Monnier <monnier@iro.umontreal.ca>:

> > 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.
>
> Try C-h f backup-by-copying TAB
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 808 bytes --]