Suggestions: Use $context parameter in copy to check the request headers (404 etc) to see if file exists and is readable) See part of "ASchmidt at Anamera dot net"'s example code in the php manual:
http://php.net/manual/en/function.copy.php#115114

@mbabker Do you know if that class ever was meant to deal with remote files?

@e-motiv for remote file try use:

$stream = JFactory::getStream();
$stream->copy($src, $dest, null, false);

Do you know if that class ever was meant to deal with remote files?

Our filesystem stuff is optimized for the local filesystem. I doubt much of it works well at all with remote data (except for things written for that, like our FTP client class).

Closing as expected behavior then.

It's a bit silly, because I've read some forum post suggestions and problems to use this for remote files, and why not since the remote-functional php function "copy" is used inside and there are some file handling (such as following configuration choice ftp or file) and others stuff inside that is reusable as a component developer.
So, can this be reopened, but as feature request? "Allow JFile::copy for remote files" ?

@Fedik
Those lines are used in JFile::copy, but with additional logic. For now, I, myself worked around it via php copy and customs logic, but thanks for the tip. It is usefull for if this feature request would be accepted as to make a context via JFile::copy or the option below..

If this is accepted as feature request, I also suggest for an option not to check the http headers (stream context) (=somewhat more developer work & server resources) but to get a filesize greater than 20 or so... (optionally)

Let me also point out that JFile::copy ís using FTP logic if option is on, so it's not really argumentative, but doesn't that more or less imply it's meant for remote files or at least ready for it?

The FTP compatibility code is really a last ditch effort thing for hosts where writing to the local filesystem is next to impossible because the environment is so poorly configured. It wasn't really designed for remote fetching from what I know.

Yeah, I realize that, hence "not really argumentative", but together with streams being available inside the function and since you mentioned it, I was just giving it as "stuff to think about" as in "we're able to do ftp on local client, make streams (even inside the same function!), allow URLs elsewhere", but JFile::copy. no remote! Anyway, ignore this if you want, it was a side remark.

"Reopen for Feature request?" is my main focus..

The FTP compatibility code is really a last ditch effort thing for hosts where writing to the local filesystem is next to impossible because the environment is so poorly configured. It wasn't really designed for remote fetching from what I know.

Imho, it's the only reason to actually use JFile::copy for anything. The whole thing is just a bandaid for bad hosts.

Really? You're talking about JFile::copy and not the FTP file handling option in general, are you?
Well, for the record, I'm using it to transfer images and pdf's from the mother-corporation to copy them to the local web server.
Why they want that? Well, I'm not sure as I am subcontracted, but I can imagine a few usefull things, to be honest.

P.S. Is this the way to make it a feature request? Discuss it here fist until someone subscribed to this topic agrees and reopens it as such? Just in case it's not, then I'd rather do it right and discuss these things in the right "scene".

You're talking about JFile::copy and not the FTP file handling option in general, are you?

I'm talking about the FTP layer included in Joomla. Which is meant to do file operations using an FTP user if the hoster for some stupid reason doesn't allow the apache user to do it. On some shared hoster this is the case.

Imho, JFile isn't meant to do what you request. So it would be the wrong place to add such functionality. If we ever decide to drop our "FTP layer for bad hosting setups", chances are high we're also going to drop a lot of the JFile methods as they serve no purpose anymore. You could as well use PHPs core methods to achieve the same.

What's wrong with using the code provided by @Fedik? Or use the JHttp class (https://api.joomla.org/cms-3/classes/JHttp.html) to access the remote files and store them afterwards. Those methods actually are meant to deal with remote ressources.