GNU bug report logs - #33573
--add-missing --copy should replace symlinks with real files

Previous Next

To reply to this bug, email your comments to 33573 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ben Elliston <bje <at> air.net.au>
To: bug-automake <at> gnu.org
Subject: --add-missing behaviour
Date: Sun, 2 Dec 2018 17:03:48 +1100

[Message part 1 (text/plain, inline)]

I ran 'automake --add-missing' to copy mdate-sh to my project. This,
of course, creates a symbolic link to the automake install tree.
Remembering this, I then ran 'automake --add-missing -c' to copy the
script instead. Since mdate-sh was already present in my tree,
automake did nothing. When passing -c, I think automake should replace
the symbolic link (if and only if it is a symbolic link).

Ben

[signature.asc (application/pgp-signature, inline)]

Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: automake-patches <at> gnu.org
Subject: [bug#33573] Patch to replace symlinks with files
Date: Wed, 28 Dec 2022 22:02:47 +0100

[Message part 1 (text/plain, inline)]

Hello, Automake gurus.

Another simple patch from my side: when '--copy' given to 
'--add-missing', copy the standard files even if symlinks already exist.

Basically, the patch adds "if --copy given and a link exists, do NOT 
exit" (+ a double-check of the object type if that would be needed on 
some systems).

This may simplify the things for some users, although you may as well 
update the documentation to say that giving "--force-missing" would 
produce the same result.

Regards,
Bogdan Drozdowski

-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

[automake-missing-link-to-file-mail.diff (text/x-patch, attachment)]

Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us
Cc: automake-patches <at> gnu.org
Subject: Re: bug#33573: Patch to replace symlinks with files
Date: Thu, 29 Dec 2022 16:33:03 -0700

    Another simple patch from my side: when '--copy' given to 
    '--add-missing', copy the standard files even if symlinks already exist.

I am not sure about changing the behavior here. Although the behavior
you propose is plausible, I fear that people might depend or expect on
failure if symlinks exist. It doesn't seem bad to me to require the user
to clean up their own symlinks, instead of assuming the overwriting
should be done. There's no way to know what the situation really is.

What I suggest is making the new behavior of deleting existing symlinks
iff -f is *also* given.  If the user says "force" and "copy" then ok, we
can figure they're asking for what they're getting.

Wdyt? --thanks, karl.

P.S. I hope to reply to your other patch in the next day or two.

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Karl Berry <karl <at> freefriends.org>
Cc: automake-patches <at> gnu.org
Subject: Re: bug#33573: Patch to replace symlinks with files
Date: Fri, 30 Dec 2022 13:04:53 +0100

Karl Berry <karl <at> freefriends.org>, Fri Dec 30 2022 00:33:03 GMT+0100 
(Central European Standard Time)
>      Another simple patch from my side: when '--copy' given to
>      '--add-missing', copy the standard files even if symlinks already exist.
> 
> I am not sure about changing the behavior here. Although the behavior
> you propose is plausible, I fear that people might depend or expect on
> failure if symlinks exist. It doesn't seem bad to me to require the user
> to clean up their own symlinks, instead of assuming the overwriting
> should be done. There's no way to know what the situation really is.
> 
> What I suggest is making the new behavior of deleting existing symlinks
> iff -f is *also* given.  If the user says "force" and "copy" then ok, we
> can figure they're asking for what they're getting.
> 
> Wdyt? --thanks, karl.


Hi.

Sure, no problem from my side. This is actually already the current 
behavior, from what I see (but I didn't check in detail). Someone 
reported a bug for this, so I simply gave it a try.

The user has a point: --copy was given, but the files were not copied. 
This may be a bit confusing. But this depends on the point of view, I 
guess, and both behaviors have a point and can be correct, depending 
on who you're asking. We can as well leave the current behavior, as 
you say: make the user be clear about what they want and maybe allow 
Automake one day behave differently (like exit with an error if a 
symlink exists and -c given, but no -f, etc.).

Just maybe make something clearer in the documentation and/or the help 
message in such case, like:


--help:
[...]
-c, --copy             with -a, copy missing files if they or their 
symlinks don't already exist (default is symlink)

-f, --force-missing    force update of standard files (with -c copies 
the files even if symlinks exist)



Automake docs:

‘-c’
‘--copy’
     When used with ‘--add-missing’, causes installed files to be
     copied if files or symlinks don't already exist.  The default is 
to make a symbolic link.



> P.S. I hope to reply to your other patch in the next day or two.


No problem - thanks for confirmation that they actually arrived. I 
thought the mails got lost in some black hole, because I'm not 
subscribed and I didn't see them in the mailing list's archive :).


-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Message #25 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us
Cc: automake-patches <at> gnu.org
Subject: Re: bug#33573: Patch to replace symlinks with files
Date: Fri, 30 Dec 2022 19:30:42 -0700

Hi Bogdan,

    Someone reported a bug for this, so I simply gave it a try.

Thank you! I didn't realize you were working on some of the old bugs.
That is great!

To bring this one in particular to fruition: can you check what happens
when -c -a would need to overwrite a symlink? I think it should just
give a warning. Then the user can decide what to do.

And, can you check that automake -a -f -c does in fact overwrite a
symlink with a copy? And, I guess, that -a -f, without the -c,
overwrites files with symlinks? (Or, if it gives an error now, that's ok
too.)

And that the test checks this stuff?

Sorry, but these are the kinds of nitty-gritty things that every
automake change needs to think about.
    
    Just maybe make something clearer in the documentation and/or the help 
    message in such case, like:

Yes, agreed. No problem there.

    I'm not subscribed 

If you intend to keep working for a while on automake (I hope so), you
should subscribe to the mailing lists, especially bug-automake and
automake-patches. Unfortunately the debbugs software does not send mail
to everyone who has been on a given bug (not even the bug originator),
but only to the associated mailing list, as I understand it.

For the same reason, it is good to explicitly cc a bug's originator and
anyone else who has contributed to the bug, if you happen to have them.

    and I didn't see them in the mailing list's archive :).

I see all your messages there now, I believe:
https://lists.gnu.org/archive/html/bug-automake/2022-12/threads.html

As I recall, there is a delay of up to an hour or maybe more before the
archives are updated. Unfortunately it does not happen when a message is
received; there's a separate polling cron job :(.

Thanks for all,
Karl

Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Karl Berry <karl <at> freefriends.org>
Cc: automake-patches <at> gnu.org
Subject: Re: bug#33573: Patch to replace symlinks with files
Date: Sat, 31 Dec 2022 20:20:40 +0100

Karl Berry <karl <at> freefriends.org>, Sat Dec 31 2022 03:30:42 GMT+0100 
(Central European Standard Time)
> Hi Bogdan,
> 
>      Someone reported a bug for this, so I simply gave it a try.
> 
> Thank you! I didn't realize you were working on some of the old bugs.
> That is great!


:)


> To bring this one in particular to fruition: can you check what happens
> when -c -a would need to overwrite a symlink? I think it should just
> give a warning. Then the user can decide what to do.


It simply doesn't do or say anything, because the object already 
exists (the subroutine simply leaves).


$ rm -f doc/texinfo.tex
$ automake --add-missing
doc/Makefile.am:1: installing 'doc/texinfo.tex'
$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:48 doc/texinfo.tex -> 
/usr/share/automake-1.16/texinfo.tex
$ automake --add-missing --copy
$



> And, can you check that automake -a -f -c does in fact overwrite a
> symlink with a copy? And, I guess, that -a -f, without the -c,
> overwrites files with symlinks? (Or, if it gives an error now, that's ok
> too.)


The combination '-a -f -c' does what's expected (replaces a symlink 
with a regular file):


$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:48 doc/texinfo.tex -> 
/usr/share/automake-1.16/texinfo.tex
$ automake --add-missing --copy
$ automake --add-missing --copy --force-missing
$ ll doc/texinfo.tex
-rw------- 1 bogdan bogdan 374230 gru 31 19:49 doc/texinfo.tex
$


That's where my idea about updating the documentation comes from - may 
not be clear enough.

Just '-a -f' does indeed replace regular files with symlinks:

$ ll doc/texinfo.tex
-rw------- 1 bogdan bogdan 374230 gru 31 19:49 doc/texinfo.tex
$ automake --add-missing --force-missing
$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:51 doc/texinfo.tex -> 
/usr/share/automake-1.16/texinfo.tex
$


$ automake --version
automake (GNU automake) 1.16.5


> And that the test checks this stuff?


 The change I'm implementing is tested by the test I've added. It 
simply checks if after --copy the file is not a link:

$AUTOMAKE --add-missing --copy
test ! -h texinfo.tex || exit 1


(unneeded parts removed)


> Sorry, but these are the kinds of nitty-gritty things that every
> automake change needs to think about.


Yes, testing and portability is important, I know.



>      Just maybe make something clearer in the documentation and/or the help
>      message in such case, like:
> 
> Yes, agreed. No problem there.
> 
>      I'm not subscribed
> 
> If you intend to keep working for a while on automake (I hope so), you
> should subscribe to the mailing lists, especially bug-automake and
> automake-patches. Unfortunately the debbugs software does not send mail
> to everyone who has been on a given bug (not even the bug originator),
> but only to the associated mailing list, as I understand it.


I see. We'll see what my future work on Automake will look like. Maybe 
I could contribute something useful. Right now, I'm planning just one 
more patch ("the last this year" - yes, it's still 2022 here :) ) and 
later we'll see what time allows. I also have my own projects to look 
after once in a while :).

Some guide like "to implement this and this, you need to change/add 
subroutine that and that" would be nice for beginners.

I wish there would be some kind of roadmap or a list of interesting 
ideas to-do in Automake. The "PLANS" doesn't have much, not for me, at 
least... Otherwise, I don't know if e.g. Automake 2.0 is implemented 
in 99% already or is it maybe just 1% and a full re-write is planned.



> For the same reason, it is good to explicitly cc a bug's originator and
> anyone else who has contributed to the bug, if you happen to have them.


I didn't want to send any notifications to the bugs in case my patches 
get rejected for some reason (like they don't work on *BSD/some 
antique Unix, don't match the programming style, etc., or are 
completely against the idea).

Furthermore, Automake doesn't get so many releases, as I see, so even 
implementing a fix doesn't mean that it will go to a release any time 
soon.



>      and I didn't see them in the mailing list's archive :).
> 
> I see all your messages there now, I believe:
> https://lists.gnu.org/archive/html/bug-automake/2022-12/threads.html
> 
> As I recall, there is a delay of up to an hour or maybe more before the
> archives are updated. Unfortunately it does not happen when a message is
> received; there's a separate polling cron job :(.


Right. They're there. Unfortunately, the Automake website points to 
https://lists.gnu.org/archive/html/automake-patches/ instead :). 
That's also where I send my mails to, not knowing they end up in 
"bug-automake". Minor issue, but may be confusing, as you can see :).

Thanks.

-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Message #31 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Bogdan <bogdro_rep <at> gmx.us>, Karl Berry <karl <at> freefriends.org>
Cc: automake-patches <at> gnu.org
Subject: Re: bug#33573: Patch to replace symlinks with files
Date: Sun, 1 Jan 2023 21:14:38 +1000

Hi both,

On 1/1/23 05:20, Bogdan wrote:
> Karl Berry <karl <at> freefriends.org>, Sat Dec 31 2022 03:30:42 GMT+0100 
> (Central European Standard Time)
>> Hi Bogdan,
>>
>>      Someone reported a bug for this, so I simply gave it a try.
>>
>> Thank you! I didn't realize you were working on some of the old bugs.
>> That is great!
>
>
> :)
>
>
>> To bring this one in particular to fruition: can you check what happens
>> when -c -a would need to overwrite a symlink? I think it should just
>> give a warning. Then the user can decide what to do.
>
>
> It simply doesn't do or say anything, because the object already 
> exists (the subroutine simply leaves).
>
>
FWIW, as a user I think this is the expected behavior. The option is 
named --add-missing, so if the file is not missing, I expect nothing to 
happen.

Cheers,

Peter

Message #34 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: trojkan <at> gmail.com
Cc: bogdro_rep <at> gmx.us, automake-patches <at> gnu.org
Subject: Re: bug#33573: Patch to replace symlinks with files
Date: Sun, 1 Jan 2023 16:02:23 -0700

    FWIW, as a user I think this is the expected behavior. The option is 
    named --add-missing, so if the file is not missing, I expect nothing to 
    happen.

I more or less agree, but the original suggestion from Ben
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33573) was for
--add-missing --copy to overwrite existing symlinks with files, because
of the --copy. So the current behavior of silently ignoring existing
entries doesn't suit everyone. But I don't think silently overwriting
symlinks is right either.

I can see that specifying both --add-missing and --copy leaves it rather
indeterminate what should happen with existing symlinks. In practice, I
doubt people would want to end up with some symlinks and some files for
the "missing" list of files, which is what would generally happen now.

Hence my idea of simply reporting the situation (not failing, just
warning), and if they want to overwrite symlinks with files, also use
--force.

It occurs to me that, in the analogous situation from the other side,
when --add-missing is given without --copy, one could argue that a
warning should equally be given if a file (not symlink) exists. But
somehow that feels like a step too far, although I can't think of a real
argument against it. --best, karl.

Message #37 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sam James <sam <at> cmpct.info>
To: Bogdan <bogdro_rep <at> gmx.us>
Cc: automake-patches <at> gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#33573: Patch to replace symlinks with files
Date: Sun, 1 Jan 2023 23:19:34 +0000

[Message part 1 (text/plain, inline)]

> On 31 Dec 2022, at 19:20, Bogdan <bogdro_rep <at> gmx.us> wrote:
> 
> Karl Berry <karl <at> freefriends.org>, Sat Dec 31 2022 03:30:42 GMT+0100 (Central European Standard Time)
> [snip]
> 
>> For the same reason, it is good to explicitly cc a bug's originator and
>> anyone else who has contributed to the bug, if you happen to have them.
> 
> 
> I didn't want to send any notifications to the bugs in case my patches get rejected for some reason (like they don't work on *BSD/some antique Unix, don't match the programming style, etc., or are completely against the idea).
> 
> Furthermore, Automake doesn't get so many releases, as I see, so even implementing a fix doesn't mean that it will go to a release any time soon.
> 

I appreciate the thought, but this is likely to be more confusing as we want feedback if possible, and you're trying - so it can't hurt.

Don't overthink it. :)

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.