From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4734 invoked from network); 22 May 2000 17:04:52 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 22 May 2000 17:04:52 -0000 Received: (qmail 21266 invoked by alias); 22 May 2000 17:04:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11514 Received: (qmail 21258 invoked from network); 22 May 2000 17:04:42 -0000 Date: Mon, 22 May 2000 18:04:15 +0100 From: Peter Stephenson Subject: Re: Proxy support for zftp functions In-reply-to: "Your message of Mon, 22 May 2000 20:35:53 +0400." <001101bfc40b$cc325c00$21c9ca95@mow.siemens.ru> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Message-id: <0FUZ00C1W0R3BH@la-la.cambridgesiliconradio.com> Content-transfer-encoding: 7BIT > The main use for it is to be able to compare times on remote/local > files. Without it no real directory sync (and even reliable reget) is > possible. Is it possible to pass file date/size from function to zftp.c > code? O.K., file mtime can be set by function as well ... Checking the time is is only ever done in the shell code; checking the size is only done by C for passing down to zftp_progress for info, so the only reason for using C code at all would be to make parsing easier. But it's certainly not a trivial problem to compare two dates from shell code, because the information about time zones is hard to get at --- for exactly that reason, the zftp functions call perl to do it for them (see the function zfrtime). I don't have a simple answer to this, but a date and time parsing and conversion module might be a nice extension --- or, of course, a piece of shell code that does it neatly, if that's possible. Come to think of it, there's a hack using the stat module for local files. % touch foo; stat -s +mtime foo; stat -g +mtime foo Mon May 22 17:59:38 Mon May 22 16:59:38 (Unfortunately you only get it as text, since the time in seconds since the epoch is always in GMT.) And how do you get the GMT modification time for a remote file reliably if you can't rely on MDTM, anyway? -- Peter Stephenson Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070