GNU bug report logs - #32127
ln: add option to fall-back to softlink if hardlink fails

Previous Next

To reply to this bug, email your comments to 32127 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: L A Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: RFE -- in the way "cp -rl"  -- enable 'ln' to do likewise?
Date: Wed, 11 Jul 2018 12:29:04 -0700

If one does a 'cp -rl' -- one gets a coyp of the tree...sorta,
with file hardlinked, and with directories getting their own set
of inodes because:
can't be hardlinked -- so no hardlinking (even if worked, wouldn't make
a separate copy) &&
can't have softlinked dirs, as to softlink something, you need something
to softlink things *to*.  If dirs were softlinked, again, the files
inside would be referenced by the same name-entry in the same real 
directory.

Instead it tries to do a useful think in creating a separate tree with
a fresh set of name entries that point to the same inode-data.

In the same way, I'm often wanting to work on some set of source
files from a different starting location in the source tree.

Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use
ln <existing RCSdir> <new RCS loc>.  ln, of course seems to think I
want the impossible -- and says you can't have hard-linked directories.

Instead, just as cp-rl only hard links files while creating new dirs
for directories in the other tree, instead of treating dirs+files the
same, and giving an error message that wouldn't be helpful.


I was wondering if ln dir1 target/ could differentiate and "do what
I meant", and create a softlink rather than giving an error and
requiring me to re enter the command with -l.

I wouldn't be against the idea of it saying that it created a softlink,
but the point it to favor it doing something useful rather than issuing an
error that isn't.

Would that be possible? 
Thanks,  Linda

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: L A Walsh <coreutils <at> tlinx.org>, 32127 <at> debbugs.gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Wed, 11 Jul 2018 13:05:25 -0700

L A Walsh wrote:
> Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use
> ln <existing RCSdir> <new RCS loc>.  ln, of course seems to think I
> want the impossible -- and says you can't have hard-linked directories.

You can use "ln -s" instead of plain "ln". If that's not what you want, then I'm 
afraid I don't understand what you want, exactly.

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 32127 <at> debbugs.gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Thu, 12 Jul 2018 00:16:50 -0700

Paul Eggert wrote:
> L A Walsh wrote:
>> Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use
>> ln <existing RCSdir> <new RCS loc>.  ln, of course seems to think I
>> want the impossible -- and says you can't have hard-linked directories.
> 
> You can use "ln -s" instead of plain "ln". If that's not what you want, then I'm 
> afraid I don't understand what you want, exactly.
---
	Yes, I can retype the command after getting an error telling
me that regular links to directories are invalid.

	I'm asking why does 'ln' bother to tell the user that they are wrong and do nothing useful?  Why not just go ahead and create a symlink -- since it is likely that is what is wanted and is the only type of link that works?

	If needed, it could even tell the user that hard links don't
work so it created a symlink instead.  That way, in the mostly likely case (user wanted a symlink and left off the '-l'), they user would have the symlink created and would not have to re-enter the command.

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

From: L A Walsh <coreutils <at> tlinx.org>
Cc: Coreutils <bug-coreutils <at> gnu.org>, Coreutils <coreutils <at> gnu.org>
Subject: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
Date: Fri, 13 Jul 2018 10:03:52 -0700

-------- Original Message --------
Subject: 	bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do 
likewise?
Resent-Date: 	Thu, 12 Jul 2018 07:17:02 +0000
Resent-From: 	L A Walsh <coreutils <at> tlinx.org>
Resent-CC: 	bug-coreutils <at> gnu.org
Date: 	Thu, 12 Jul 2018 00:16:50 -0700
From: 	L A Walsh <coreutils <at> tlinx.org>
To: 	Paul Eggert <eggert <at> cs.ucla.edu>
CC: 	32127 <at> debbugs.gnu.org
References: 	<5B465A80.8030104 <at> tlinx.org> 
<a8b9d013-8886-5b8a-741b-50219255f94a <at> cs.ucla.edu>



Paul Eggert wrote:
> L A Walsh wrote:
>> Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use
>> ln <existing RCSdir> <new RCS loc>.  ln, of course seems to think I
>> want the impossible -- and says you can't have hard-linked directories.
> 
> You can use "ln -s" instead of plain "ln". If that's not what you want, then I'm 
> afraid I don't understand what you want, exactly.
---
	Yes, I can retype the command after getting an error telling
me that regular links to directories are invalid.

	I'm asking why does 'ln' bother to tell the user that they are wrong and do nothing useful?  Why not just go ahead and create a symlink -- since it is likely that is what is wanted and is the only type of link that works?

	If needed, it could even tell the user that hard links don't
work so it created a symlink instead.  That way, in the mostly likely case (user wanted a symlink and left off the '-l'), they user would have the symlink created and would not have to re-enter the command.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 32127 <at> debbugs.gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Fri, 13 Jul 2018 16:40:42 -0500

On 07/12/2018 02:16 AM, L A Walsh wrote:
>
>     I'm asking why does 'ln' bother to tell the user that they are
> wrong and do nothing useful?  Why not just go ahead and create a symlink

The user didn't ask for a symlink, and it sounds unwise for ln to be
second-guessing that. Sometimes, reporting an error and exiting is a
better thing to do.

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Coreutils <bug-coreutils <at> gnu.org>, Coreutils <coreutils <at> gnu.org>,
 32127 <at> debbugs.gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Fri, 13 Jul 2018 15:17:03 -0700

Paul Eggert wrote:
> On 07/12/2018 02:16 AM, L A Walsh wrote:
>>     I'm asking why does 'ln' bother to tell the user that they are
>> wrong and do nothing useful?  Why not just go ahead and create a symlink
> 
> The user didn't ask for a symlink, and it sounds unwise for ln to be
> second-guessing that. Sometimes, reporting an error and exiting is a
> better thing to do.

Often in deciding whether it is good or not good to make a reasonable
attempt at completion factors are evaluated --  such as consequences
for trying or not trying and whether or not the user is running
interactively or not, and the likelihood of the possible solution being
what they wanted.

In this case, it seems they wanted some type of link created or they would not have used the link command.  If they link was created as a symlink because hardlinks are not available, then they have solved their problem.  If the link isn't created because hardlinks are not supported (even though they did not specify the link type (-P|-s) then ln would fail and they would need to redo the command.  

If they didn't want the link created, it would be unlikely they'd be using the 'ln' (link) command.  

Only in the case that they wanted a link -- but only a hard link, would they need to remove it -- 'ln' would have failed to do the right thing.


I posit that they wouldn't need to create a hard link in a workable
solution -- they will need to find some other way to create a solution ( perhaps mounting the file).  However if they are not root, they won't be able to use that solution.  I would suggest that it would be unlikely that they would need a hard link there and they might change their mind and decide that a symlink is fine.


In all of the cases, given the probabilities, it would be most helpful and most useful to create *some link*, as that is what they asked for by using the 'ln' command.  Non of the outcomes require any more correction than undoing the incorrect action, but it is likely they would agree that a symbolic link was the right choice given that physical links are not
available.

You said "The user didn't ask for a symlink".  Neither did they hask
for a hardlink by using "-P'.  They wanted a link.  Creating the only
possible link would seem to be the best option available.

Indeed -- my focus was on creating a link -- that it had to be a symlink
was a bit of minutia that I didn't care much about.  If I had stated that
I wanted a physical link by specifying "-P" -- then I would not suggest
auto-creating the link -- only in the case where a link was asked for
without specification of type.

Frequently is is more user friendly to do something than do nothing (assuming doing something doesn't cause damage -- which is the case here.

-L.

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Coreutils <bug-coreutils <at> gnu.org>, Coreutils <coreutils <at> gnu.org>,
 32127 <at> debbugs.gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Sat, 14 Jul 2018 10:51:22 -0700

Paul Eggert wrote:
> On 07/12/2018 02:16 AM, L A Walsh wrote:
>>     I'm asking why does 'ln' bother to tell the user that they are
>> wrong and do nothing useful?  Why not just go ahead and create a symlink
> 
> The user didn't ask for a symlink,
User didn't ask for a physical or hardlink (-P) either.  Just asked
for a link, kind unspecified.

> and it sounds unwise for ln to be
> second-guessing that.
---
 True - should **probably** have given them *SOME* link.  Since
they didn't specify Physical or Symlink...either would be fine.


> Sometimes, reporting an error and exiting is a
> better thing to do.
---
	Unless they claim to want one or the other (-P or -l), unless
it is an "undo-able" operation (like one that deletes data), why would
you guarantee ln doing the wrong thing, rather than having a better than
50% chance of doing the right thing?

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: L A Walsh <coreutils <at> tlinx.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: coreutils <at> gnu.org, 32127 <at> debbugs.gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Mon, 16 Jul 2018 23:14:21 +0200

On 07/14/2018 07:51 PM, L A Walsh wrote:
> Paul Eggert wrote:
>> On 07/12/2018 02:16 AM, L A Walsh wrote:
>>>     I'm asking why does 'ln' bother to tell the user that they are
>>> wrong and do nothing useful?  Why not just go ahead and create a symlink
>>
>> The user didn't ask for a symlink,
> User didn't ask for a physical or hardlink (-P) either.  Just asked
> for a link, kind unspecified.
> 
>> and it sounds unwise for ln to be
>> second-guessing that.
> ---
>   True - should **probably** have given them *SOME* link.  Since
> they didn't specify Physical or Symlink...either would be fine.
> 
> 
>> Sometimes, reporting an error and exiting is a
>> better thing to do.
> ---
> 	Unless they claim to want one or the other (-P or -l), unless
> it is an "undo-able" operation (like one that deletes data), why would
> you guarantee ln doing the wrong thing, rather than having a better than
> 50% chance of doing the right thing?

I disagree here: some people are not that familiar with the differences
between symlinks and hardlinks, okay, but the consequences for using either
type may be quite dramatic later on.  Therefore I think it's better to give
a helping error instead of second-guessing what the user *may* have wanted.
The point is: also an experienced user may sometimes forget to specify
the -s option, and I'm sure they *want* a proper error message.

Have a nice day,
Berny

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Coreutils <bug-coreutils <at> gnu.org>,
 coreutils <at> gnu.org, 32127 <at> debbugs.gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Tue, 17 Jul 2018 01:25:59 -0700

Bernhard Voelker wrote:

> 
> I disagree here: some people are not that familiar with the differences
> between symlinks and hardlinks, okay, but the consequences for using either
> type may be quite dramatic later on.
----
	I am not suggesting handing out alternates when you have a
choice.  I'm suggesting doing something useful in a case where there are
no alternates and no downsides.  If you can come up with a case where
a symlink to a directory would do more harm than a hardlink, I might agree,
but in this case, hardlinks are not supported.  So there can be no
"dramatic consequences".  I.e. that sounds more like FUD for the sake
of argument than a sound engineering analysis.

> Therefore I think it's better to give
> a helping error instead of second-guessing what the user *may* have wanted.
----
	I said doing both would be fine -- i.e. creating the symlink
and issuing a warning that a symlink was used.

> The point is: also an experienced user may sometimes forget to specify
> the -s option, and I'm sure they *want* a proper error message.
----
	I think I'd fall into the category of experienced user -- more
so than most.  I really don't care about a proper error message nor do I
prefer to type in '-s'.  I just wanted the link of the right type for
linking to a directory.  Your example of what an experience user would want
is conjecture, and in this case, incorrect.  Additionally, your initial
argument refers to cases that cannot occur or happen w/modern linux (or 
unix) systems.  I repeat -- what dramatic consequence could happen here
where the user got a symbolic link, but somehow expected expected a hard
link -- what worse behavior would a symbolic link enable that wouldn't have
happened with a hard or physical link?

	If you can come up with a realistic case where such code 
creates dramatic effects/consequences, then lets have a discussion on real
problems -- not on things that don't exist.

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

From: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, L A Walsh <coreutils <at> tlinx.org>,
 coreutils <at> gnu.org, 32127 <at> debbugs.gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Tue, 17 Jul 2018 11:20:08 +0200

Hi,

On Mon, Jul 16, 2018 at 11:14:21PM +0200, Bernhard Voelker wrote:
> On 07/14/2018 07:51 PM, L A Walsh wrote:
> > Paul Eggert wrote:
> >> On 07/12/2018 02:16 AM, L A Walsh wrote:
> >>>     I'm asking why does 'ln' bother to tell the user that they are
> >>> wrong and do nothing useful?  Why not just go ahead and create a symlink
> >>
> >> The user didn't ask for a symlink,
> > User didn't ask for a physical or hardlink (-P) either.  Just asked
> > for a link, kind unspecified.
> > 
> >> and it sounds unwise for ln to be
> >> second-guessing that.
> > ---
> >   True - should **probably** have given them *SOME* link.  Since
> > they didn't specify Physical or Symlink...either would be fine.
> > 
> > 
> >> Sometimes, reporting an error and exiting is a
> >> better thing to do.
> > ---
> > 	Unless they claim to want one or the other (-P or -l), unless
> > it is an "undo-able" operation (like one that deletes data), why would
> > you guarantee ln doing the wrong thing, rather than having a better than
> > 50% chance of doing the right thing?
> 
> I disagree here: some people are not that familiar with the differences
> between symlinks and hardlinks, okay, but the consequences for using either
> type may be quite dramatic later on.  Therefore I think it's better to give
> a helping error instead of second-guessing what the user *may* have wanted.
> The point is: also an experienced user may sometimes forget to specify
> the -s option, and I'm sure they *want* a proper error message.

Just as food for thought: how about adding an option to ln to try to do
the right thing? That option could be used in an alias so that it is not
needed to always type it. Perhaps in time some GNU/Linux distributions
even add that option to their default aliases.

The option name could be --do-what-i-mean or --do-the-right-thing
or --fallback-symbolic (I am quite sure everyone can come with
additionalsuggestions. ;) Please do not take these suggestions too
seriously. ;-)

Anyway, I understand both sides of this discussion, and I definitely do
not expect anyone to go ahead and implement my solution. It is just a
suggestion for whomever wants to have this functionality, and intends
to implement it themselves, on how to find a compromise that might be
acceptable upstream.

Peace,
Erik
-- 
Be water, my friend.
                        -- Bruce Lee

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

From: Michael Stone <mstone <at> debian.org>
To: coreutils <at> gnu.org, Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Tue, 17 Jul 2018 08:51:59 -0400

On Tue, Jul 17, 2018 at 01:25:59AM -0700, L A Walsh wrote:
>	I am not suggesting handing out alternates when you have a
>choice.  I'm suggesting doing something useful in a case where there are
>no alternates and no downsides.  If you can come up with a case where
>a symlink to a directory would do more harm than a hardlink, I might agree,
>but in this case, hardlinks are not supported.  So there can be no
>"dramatic consequences".  I.e. that sounds more like FUD for the sake
>of argument than a sound engineering analysis.

You want to change the semantics of a command that's been around for 40 
years, which can be used as an atomic primitive, which has the very 
simple semantics of "make this hard link or fail", and your idea of a 
"sound engineering analysis" is "I don't see how this could cause a 
problem"?

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

From: L A Walsh <coreutils <at> tlinx.org>
To: coreutils <at> gnu.org, Coreutils <bug-coreutils <at> gnu.org>
Cc: mstone <at> debian.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Tue, 17 Jul 2018 14:15:14 -0700

Michael Stone wrote:
> On Tue, Jul 17, 2018 at 01:25:59AM -0700, L A Walsh wrote:
>   
>> 	I am not suggesting handing out alternates when you have a
>> choice.  I'm suggesting doing something useful in a case where there are
>> no alternates and no downsides.  If you can come up with a case where
>> a symlink to a directory would do more harm than a hardlink, I might agree,
>> but in this case, hardlinks are not supported.  So there can be no
>> "dramatic consequences".  I.e. that sounds more like FUD for the sake
>> of argument than a sound engineering analysis.
>>     
>
> You want to change the semantics of a command that's been around for 40 
> years, which can be used as an atomic primitive, which has the very 
> simple semantics of "make this hard link or fail", and your idea of a 
> "sound engineering analysis" is "I don't see how this could cause a 
> problem"?
>   
----
   I can't think of a similar failure mode that I'd want a hard link
created, so I can't say I'd be in favor of that or not.

   In this case, we aren't talking about atomic primitives -- or hard
links.  If you can make a hard link to a directory, I'll stand corrected,
but this is using 'ln' to create a sym link to a directory -- something
that can't fail in standard linux.

I don't see how this could cause a problem = I see no way for this to cause
a problem =>  I assert it can't in normal usage.  If you create an OS where
symlinking a directory removes it, then that is not what we are talking
about here.

OTOH, Just as redhat et al changed the semantics of both symlinks and
hardlinks via a setting in the kernel, I suppose a solution could be
implemented there: if the kernel detects an attempted hardlink to a
directory, it creates a symlink instead.

Do you really see modifying the linux kernel and how it handles links as
being safer than adding the proposed behavior to 'ln'?  I would be 
surprised if many linux users knew where to disable the new behaviors 
(which are enabled
by default in many distros) that change default semantics.  I suspect
most users weren't even aware of the change, though I hit the change on
the first new kernel with the features.  The features were based on 2 linux
security firms -- one being gr_security -- the company that tried to silence
a security researcher pointing out their poor security practices.

A review of the stated reasons for making these kernel changes points to
their them being necessary to get around other poor security decisions
that most unix old-hands knew ages ago -- reasons for having tmp files on
separate partitions from user, tmp, and system files, and reasons why adding
new security features that don't apply to root can cause problems.
(most users can rely on not accidently overwriting someone elses files in
/tmp.  Since root can override such restrictions, they can more easily
be exposed to disintegrous files.

Anyway, since only values 0/1 were used for symlink control, it would be
easy to say, value==2, would auto create a symlink to a dir when any
type of link is attempted. 

Of course, I was just suggesting an ease-of-use change for the 'ln' program
to create the only viable type of link one can make when trying to make
one pointing to a directory.  But if you think that's too risky despite
not being able to come up with any solid examples, then the same feature 
could
be built into the kernel and probably with less FUD.

Note that the the change to ln was to follow along in the path of 'cp 
-rl', where even though hard-linking is specified, "creates" directories 
-- which
would seem to violate your "atomic primitive" behavior, no?






>
>
>   

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

From: Michael Stone <mstone <at> debian.org>
To: coreutils <at> gnu.org, Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Tue, 17 Jul 2018 21:36:47 -0400

On Tue, Jul 17, 2018 at 02:15:14PM -0700, L A Walsh wrote:
>   I can't think of a similar failure mode that I'd want a hard link
>created

Yes, you've made that clear

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

From: L A Walsh <coreutils <at> tlinx.org>
To: coreutils <at> gnu.org, Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to
 do	likewise?
Date: Wed, 18 Jul 2018 03:23:59 -0700

Michael Stone wrote:
> On Tue, Jul 17, 2018 at 02:15:14PM -0700, L A Walsh wrote:
>>   I can't think of a similar failure mode that I'd want a hard link
>> created
> 
> Yes, you've made that clear
---
	I think you are making it clear that you didn't
understand what I said and why I said it.

	I said that I could not think of a similar situation 
that would involve creating a hard link by default, as I would
not be less than 50% certain it was what was wanted.

	That is directly the opposite of my initial proposal
to handle directories differently and default to the only
option that works rather than assuming they got it wrong
and issuing an error message and not doing anything useful
for them.

	You seem to think my positions on the two types of links
would be the same when they are not.  In almost any
circumstance where you could create a hardlink, you could also
create a symlink -- I.e. if you *wanted* to try to do what the
user wanted, there is no way to know -- since there are two
possibilities.

	In the case of creating a link to a directory there is
no choice in creating a "working solution".  If you want a link 
there, it HAS to be a symlink.  That the user would bother to
use the 'ln' (link) command in the first place is a sufficiently
convincing "argument" that they really DID want a link there.
That they didn't explicitly specify the type should additionally
be taken that they didn't care enough to specify the type -- only
that the link be created.

	I hope that clarifies that I'm not attempting to always
find some "automatic action", but saw that in this case, it
wouldn't be hard to figure out what was wanted and that doing
so wouldn't be hard to undo if it was not.

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

From: Mike Hodson <mystica <at> gmail.com>
To: coreutils <at> tlinx.org
Cc: bug-coreutils <at> gnu.org, Coreutils <coreutils <at> gnu.org>
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Wed, 18 Jul 2018 04:36:44 -0600

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

On Wed, Jul 18, 2018 at 4:24 AM L A Walsh <coreutils <at> tlinx.org> wrote:

> In the case of creating a link to a directory there is
> no choice in creating a "working solution".  If you want a link
> there, it HAS to be a symlink.  That the user would bother to
> use the 'ln' (link) command in the first place is a sufficiently
> convincing "argument" that they really DID want a link there.
> That they didn't explicitly specify the type should additionally
> be taken that they didn't care enough to specify the type -- only
> that the link be created.
>
>         I hope that clarifies that I'm not attempting to always
> find some "automatic action", but saw that in this case, it
> wouldn't be hard to figure out what was wanted and that doing
> so wouldn't be hard to undo if it was not.
>
>
>
I wager that some people *aren't* aware that you cannot hardlink a
directory, and instead of writing hundreds of NEW bug reports "linking
broken" "why can't I link a directory" leaving 'ln' as it has been since
the dawn of time is the better option.

You don't think this will happen? I assure you it will.

Look at the YEARS of new users being introduced, as their distributions
finally 'stabilize' newer coreutils, to the new "Quoted Filenames" in 'ls'
. So many people have been totally confused, angry, and rather taken aback
that such an old utility did something different.

Even when it could be argued(and I said exactly this when I saw the new
feature)  "Hey, thats pretty cool, i can cut and paste with a mouse now and
it won't require manual editing later" and many people have made this
argument; many other people have made the argument of "if its not in an
interactive terminal, NOTHING CHANGED" because so many thought that "well
crap I can't rely on any scripts to work anymore"

...

Let us all learn from history, on this same maillist, of when and when not
to change the default workings of a 40 year old tool.
Perhaps, there are better things to do with the time than argue a point
that will cause NUMEROUS people grief in the future.

Mike

[Message part 2 (text/html, inline)]

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

From: Michael Stone <mstone <at> debian.org>
To: coreutils <at> gnu.org, Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Wed, 18 Jul 2018 10:18:19 -0400

On Wed, Jul 18, 2018 at 03:23:59AM -0700, L A Walsh wrote:
>	In the case of creating a link to a directory there is
>no choice in creating a "working solution".  If you want a link there, 
>it HAS to be a symlink.  That the user would bother to
>use the 'ln' (link) command in the first place is a sufficiently
>convincing "argument" that they really DID want a link there.
>That they didn't explicitly specify the type should additionally
>be taken that they didn't care enough to specify the type -- only
>that the link be created.

Or, they expect the traditional behavior, which is that requesting a
link which can't be created will result in failure. You seem to 
completely disregard the possibility that any script written in 40 years 
might use that behavior in its logic, while I find it extremely unlikely 
that scripts would be written in the hope that someday the behavior 
might change and things work differently because they make more sense 
that way.

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

From: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
To: coreutils <at> gnu.org, bug-coreutils <at> gnu.org
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Wed, 18 Jul 2018 17:27:54 +0200

Hi,

On Wed, Jul 18, 2018 at 04:36:44AM -0600, Mike Hodson wrote:
> On Wed, Jul 18, 2018 at 4:24 AM L A Walsh <coreutils <at> tlinx.org> wrote:
> 
> > In the case of creating a link to a directory there is
> > no choice in creating a "working solution".  If you want a link
> > there, it HAS to be a symlink.  That the user would bother to
> > use the 'ln' (link) command in the first place is a sufficiently
> > convincing "argument" that they really DID want a link there.

This sounds reasonalble to me: a link was requested, it might not matter
which kind, and only one kind of link can be created. Thus 'ln' could
try to do the right thing and create a (symbolic) link.

> > That they didn't explicitly specify the type should additionally
> > be taken that they didn't care enough to specify the type -- only
> > that the link be created.
> >
> >         I hope that clarifies that I'm not attempting to always
> > find some "automatic action", but saw that in this case, it
> > wouldn't be hard to figure out what was wanted and that doing
> > so wouldn't be hard to undo if it was not.
> 
> I wager that some people *aren't* aware that you cannot hardlink a
> directory, and instead of writing hundreds of NEW bug reports "linking
> broken" "why can't I link a directory" leaving 'ln' as it has been since
> the dawn of time is the better option.

Printing a helpful warning message that a symbolic link has been created
instead of a hard link, because a hard link cannot be created (perhaps
less verbose) would help at least a little bit. A new option that is
needed to enable that behavior would prevent the confused users, until
distributions start to add it to the default aliases.

> You don't think this will happen? I assure you it will.
> 
> Look at the YEARS of new users being introduced, as their distributions
> finally 'stabilize' newer coreutils, to the new "Quoted Filenames" in 'ls'
> . So many people have been totally confused, angry, and rather taken aback
> that such an old utility did something different.

I immediatly searched for the respective option and changed my aliases
to not quote 'ls' output. ;-)

I did not like that the default output of 'ls' was changed, but at least
I can disable this anti-feature.

> Let us all learn from history, on this same maillist, of when and when not
> to change the default workings of a 40 year old tool.

This sounds reasonable to me, but others have different view, see your
'ls' example. ;-)

Anyway, IMHO Linda's arguments for the specific change requested
have merit. I personally would prefer an option to enable that new
functionality instead of making it the default, if someone were to
implement said functionality.

Thanks,
Erik
-- 
Design your product to please the users.
                        -- Paul Graham

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Mike Hodson <mystica <at> gmail.com>
Cc: bug-coreutils <at> gnu.org, Coreutils <coreutils <at> gnu.org>
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
 likewise?
Date: Wed, 18 Jul 2018 15:15:44 -0700

Mike Hodson wrote:

> I wager that some people *aren't* aware that you cannot hardlink a directory 
----
	If they don't know why, they probably don't know the difference
between hard and soft links to files -- and will *then* be annoyed that
linking doesn't work.  *THEN*, they will your "hundreds of NEW 
bug reports 'linking broken' 'why can't I link a directory' -- all because
ln creates no link nor gives an explanation.  

My suggestion does both -- create a link that they obviously wanted, 
of the only type that works (as no link type was specified(**) ), AND warn
that "A symlink was created, as hard-linking to a directory is
not supported".

(**) - if they go so far as to use '-P'/'--physical', then I would suggest
NOT creating the symlink. 

That addresses the issue of people filing 100's of new bug reports
as it tells them why -- it's not supported.

The message "hard link not allowed for directory" is also inaccurate.
It says hard linking is not "allowed" (permitted), suggesting it could
be.  Saying 'not supported' says nothing about permissions.


> Look at the YEARS of new users being introduced, as their distributions 
> finally 'stabilize' newer coreutils, to the new "Quoted Filenames" in 
> 'ls' . So many people have been totally confused, angry, and rather 
> taken aback that such an old utility did something different.
---
	Because someone chose to *add* quotes by default when there
was already an option to add them.  They changed the default on a
personal whim.  It's not the case that without quotes nothing will
work.  It was an *arbitrary* choice for change among several choices
that were already present.



> Even when it could be argued(and I said exactly this when I saw the new 
> feature)  "Hey, thats pretty cool, i can cut and paste with a mouse now 
> and it won't require manual editing later"
---

	Sigh...untrue.  Maybe someone new who hadn't developed a workflow
to handle such input would like it.  Anyone who had been around "a while"
would have developed a workaround, *if* it bothered them.  That workflow
broke with the new change:

> /bin/ls -1
<output> 	# that I Copy+Paste as such:
readarray -t files
<paste>
^D
## now my filenames w/spaces in them or whatever, are in 'files'
# now try to use the files like 'ls "${x[@]}"'
> ls "${x[@]}"
ls: cannot access "'Anime/D. Gray-man'": No such file or directory
ls: cannot access ' Anime/DGreyMan-「ディー・グレイマン」オリジナル・サウンドトラック　２': No such file or directory
ls: cannot access "'Anime/Daphne In The Brilliant Blue'": No such file or directory
ls: cannot access "'Anime/Darling in the FranXX'": No such file or directory
ls: cannot access "'Anime/Devil Survivor 2 - The Animation OST'": No such file or directory
ls: cannot access "'Anime/Dragonaut - The Resonance OST'": No such file or directory

----

	Total SNAFU.


> many other people have made the argument of "if its not 
> in an interactive terminal, NOTHING CHANGED" because so many thought 
> that "well crap I can't rely on any scripts to work anymore" \
---
	If I never ran interactively, I wouldn't have noticed (nor
would I already have a workaround).  

	So it was 1) arbitrary, 2) already had an option to do 
it (could have been done w/aliases) and 
3) it broke existing workflows ==>>  Bad Change.

	The proposed change, however fixes an error condition
as well as provides the workaround, automatically (with an
optional explanation).  The two cases are VERY different.

-l

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

From: L A Walsh <coreutils <at> tlinx.org>
To: coreutils <at> gnu.org, Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to
 do	likewise?
Date: Wed, 18 Jul 2018 21:22:21 -0700

Michael Stone wrote:


> Or, they expect the traditional behavior, which is that requesting a
> link which can't be created will result in failure. You seem to 
> completely disregard the possibility that any script written in 40 years 
> might use that behavior in its logic, while I find it extremely unlikely 
> that scripts would be written in the hope that someday the behavior 
> might change and things work differently because they make more sense 
> that way.
---
	Like I said....putting change into the kernel to do the same --
seems to fly by with little or no comment...  Putting it in an app
where it is visible...and everyone complains.  Interesting.

Apps that rely on getting errors?  You don't regard that as a bit
of an unreliable design?  But easily solved -- go the way of 'ls'
and only create the symlinks if the process is interactive.

Problem solved

Previous Next

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