From mboxrd@z Thu Jan 1 00:00:00 1970 From: urgrue Subject: Re: "resume" cp/mv Date: Tue, 07 Feb 2006 17:50:16 +0200 Message-ID: <43E8C1B8.1070601@bulbous.org> References: <43E76B06.50201@bulbous.org> <42c5b570602062328k353945f7hc53d1448e939e718@mail.gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <42c5b570602062328k353945f7hc53d1448e939e718@mail.gmail.com> Sender: linux-admin-owner@vger.kernel.org List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Prosenjit Kundu Cc: "hansel@hansel.mnstate.edu" , linux-admin@vger.kernel.org rsync certainly helps with large directories, so thats at least a partial solution, but it doesnt resume an interrupted transfer of an individual file, does it? Prosenjit Kundu wrote: > I have also used 'cp -u'.......but rsync is better match for it. > > PK > > On 2/6/06, hansel@hansel.mnstate.edu wrote: >> I've used 'cp -u' for a similar problem (where I really am updating >> parallel --backup-- directories of huge graphics files). >> >> Mark Hansel >> >> On Mon, 6 Feb 2006, urgrue wrote: >> >>> Anyone know of any trick to make mv/cp support some form of crash-recovery? >>> >>> The problem is, if I'm moving a huge directory/file, and the transfer >>> fails, there is absolutely no way to continue where I left off. This is >>> awfully primitive. >>> >>> The only way I can think of is to zssh into my own localhost and use >>> rz/sz, or the same via ftp, but this seems like a pathetic kludge, and >>> even those dont work very well with large directories full of files. >>> - >> - >> To unsubscribe from this list: send the line "unsubscribe linux-admin" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > -- > Regards, > Prosenjit Kundu > - > To unsubscribe from this list: send the line "unsubscribe linux-admin" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html