From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kin Cho Newsgroups: gmane.emacs.help Subject: Re: tramp: Maximum buffer size exceeded Date: 29 Aug 2003 15:41:14 -0700 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <7iy8xcnl2t.fsf@neoscale.com> References: <7id6epp3z7.fsf@neoscale.com> <84r834uto9.fsf@slowfox.is.informatik.uni-duisburg.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1062197622 992 80.91.224.253 (29 Aug 2003 22:53:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 29 Aug 2003 22:53:42 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Aug 30 00:53:40 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19ss7g-0000sR-00 for ; Sat, 30 Aug 2003 00:53:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19ss2i-00055U-9N for geh-help-gnu-emacs@m.gmane.org; Fri, 29 Aug 2003 18:48:32 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!12.24.46.66!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 42 Original-NNTP-Posting-Host: 12.24.46.66 Original-X-Trace: news.uni-berlin.de 1062196877 12040883 12.24.46.66 (16 [151019]) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Original-Xref: shelby.stanford.edu gnu.emacs.help:116275 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:12193 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:12193 kai.grossjohann@gmx.net (Kai Großjohann) writes: > Kin Cho writes: > > > tramp (2.0.35) seems to have trouble with large file size. > > > > I was trying to copy /large-file (210 Meg) from foobar to a local > > directory. > > It's a pity. I didn't think of this optimization. If you look at > the function tramp-do-copy-or-rename-file, then you will see that it > deals with the following special cases: > > * Both are Tramp files. In that case, I look whether they are from > the same user/host/method combo. If so, I invoke "mv"/"cp" on the > remote system directly. If not, see the last case. > > * Neither are Tramp files. Error. > > * This is the default case: fetch file into a buffer, then save the > buffer. > > I should add another case which looks whether exactly one of them is > remote and the method is an out of band method. In that case, I can > invoke rcp/scp/... directly. > > Want to code this? I'll take a shot at it. However, since I don't copy these large files often (may be once a month), and even then it's easy to manually type the scp command anyway. My sense of urgency to work on this will be low. Speaking of urgency, one thing that comes to mind as being more urgently needed is to optimize tramp startup connection time. An idea I had was to cache the little things that tramp sends to the remote host. That way, tramp would startup much quicker the next time it connects to the same host. -kin