Re: disabling local-to-local transfers?

I've had that behaviour bite me a few times, too.


> scp does not open or read ~/.ssh/config
> 
> Having scp open and parse that file, which requires thousands of lines
> of code in the option parser doesn't make sense.

Well, then make it read a ~/.ssh/scp.config file,
or simply test for an environment variable.

"scp" as protocol is deprecated in favour of sftp anyway.


> It is highly likely that someone has a script running scp inside some
> sort of filesystem containment mechanism that would fail
> catastrophically because the ~/ directory is intentionally hidden, and
> therefore break the command will behave differently, and someone's data
> pipeline will develop a "new behavior".

Well, this shouldn't arise with an environment variable.


> The code which does this was in the ancestor rcp.c before many of you
> were born.
> 
> It is too late.
> 
> I have personally spent decades working with others to change the
> behaviour of established programs for various reasons, and always the
> process is to re-discover all behaviours that stand in the way of a
> change, then prototype fixes for those existing use cases to satisfy 
> the
> new proposed behaviour, OR recognize that the behaviour change faces 
> too
> high a barrier and find a different way or abandon the effort.  That is
> not being done by anyone here, so the proposal and request is
> uneducated, unjustified, and frankly irresponsible.

I understand you --
I've been fighting legacy behaviour too from time to time.

But that shouldn't stop us proposing and implementing ideas,
just to think about the effects a bit longer.


I see that "scp" is broken for local usage --
it doesn't copy xattrs:

   $ date > foo
   $ xattr -w user.attr_name attr_value foo
   $ xattr foo
   user.attr_name
   $ scp foo bar
   $ xattr bar
   $

Yeah, it just runs the "cp" binary with a few options,
but that doesn't make it correct.
(Simply adding "-a", "--preserve", or whatever runs
into compatibility problems again, so that's not an option ;)


Perhaps it would be a good idea to disallow local-to-local copies
_unless_ some environment variable is set?

Old, unmaintained systems would never see the changed behaviour,
new users would be spared the problem,
and the very few people that encounter this new error
could just read from it which environment variable to set
(locally, globally, whatever) to get that usecase working again.