[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?
From: |
L A Walsh |
Subject: |
Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise? |
Date: |
Tue, 17 Jul 2018 01:25:59 -0700 |
User-agent: |
Thunderbird |
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.
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, L A Walsh, 2018/07/13
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, L A Walsh, 2018/07/14
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, Bernhard Voelker, 2018/07/16
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?,
L A Walsh <=
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, Michael Stone, 2018/07/17
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, L A Walsh, 2018/07/17
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, Michael Stone, 2018/07/17
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, L A Walsh, 2018/07/18
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, Mike Hodson, 2018/07/18
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, Erik Auerswald, 2018/07/18
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, L A Walsh, 2018/07/18
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, Michael Stone, 2018/07/18
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, L A Walsh, 2018/07/19
- Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?, Erik Auerswald, 2018/07/17