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

Previous Next

Full log

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

Previous Next

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