savannah: fish copies files to tmp before transfer -> fails with low disk space

[tropikhajma]

Original: ​http://savannah.gnu.org/bugs/?21692

Submitted by:	hajma <tropikhajma>	Submitted on:	Sat 01 Dec 2007 02:34:28 PM UTC
Category:	VFS	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	4.6.1	Operating System:	GNU/Linux

Original submission:

To reproduce:
1. have a machine with a 4G file on it and just 1G free space
2. mc
3. Left -> Shell connection, enter remote machine name and connect
4. In the right pane, locate the big file and hit F5 to copy it to 
the remote machine

result:
while mc pretends it is transferring the file to the remote machine,
it is actually copying it to ~/tmp/mc-$USER.
If I had enough space it would start transfer AFTER the file is 
completely copied (after it CLAIMS to user 100% was transferred).
But since I do not have this much space, I am SOL and it fails.

mc --version
GNU Midnight Commander 4.6.1
Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, undelfs
With builtin Editor
Using system-installed S-Lang library with terminfo database
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With internationalization support
With multiple codepages support

Mandriva Linux 2008.0 here

the patches applied by distribution are available here:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2008.0/mc/current/SOURCES/

[covex]

Replying to slavazanko:

Original: ​http://savannah.gnu.org/bugs/?21692

Submitted by:	hajma <tropikhajma>	Submitted on:	Sat 01 Dec 2007 02:34:28 PM UTC
Category:	VFS	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	4.6.1	Operating System:	GNU/Linux

This bug makes long term annoyance to me.
First it prohibits to copy files bigger than /tmp free space which makes it useless on systems with small footprint or readonly FS. Second it slows down smaller files copiing at least two times, as it first copies to tmp, then transfers. During the copy, there is of course no transfer.

I am not sure why it was implemented this way.

The patch included in ​http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2008.0/mc/current/SOURCES/mc-fish-upload.patch?revision=95698&view=markup
does not seem to me as overkill to implement.

[slavazanko]

(In #68) In my point of view, need to resolve #77 issue first, then probably this ticket will be non-actual. If not - we will continue development from this point.

[god12]

Is there a way to at least configure the tmp location as a temporary workaround?

[enerccio]

Can someone explain to me why is this STILL not fixed in 11 years? Really? This is one of the fundamental bugs that can crash servers when person who does not know about this "feature" attempts to copy large data via ssh and eats all unnecessary space and then applications that monitor space will go haywire. Seriously, it's 2020, there has to be way to NOT use tmp when transferring via ssh or ftp.

[andrew_b]

Ticket #4197 has been marked as a duplicate of this ticket.

[andrew_b]

Ticket #4227 has been marked as a duplicate of this ticket.

[lacmuch]

the most annoying thing ever in mc :-( I can't imagine why can't copy the file directly

[nsauzede]

It's 2024 now; and this annoying/blocking bug is still there.
Is it possible to fix it, to avoid having to manually use scp outside of mc ?
Maybe mc could use a simple "scp src dest" command, which would solve the issue ?
I guess that the current "copy to /tmp" behaviour could be kept for nonlocal-filesystem cases (eg: copying from within a compressed archive); but really, when the source is a local-filesystem regular file, it would make sense to just use scp, when available, right ?

[zaytsev]

FISH *is* implemented as a non-local file system, it should be used if you have shell access to the server, but no other possibilities to transfer files. If you can use scp, then you should use SFTP file system, it shouldn't have this problem.