I'm using the Cygwin SSH server. I looked through the code from your link below 
to see what it expects from the SSH server and thought it might be a problem 
with parseTLine() in the Scp class, but I get the following when I run a 
debugging command against the SSH server:

$ scp -p -v [EMAIL PROTECTED]:/cygdrive/c/temp/ftp/repository/zilliant/policymg
t_campaignmanager_swingui/6.5.0.0/ivy.xml .
Executing: program /usr/bin/ssh host localhost, user chilton, command scp -v -p
-f /cygdrive/c/temp/ftp/repository/zilliant/policymgt_campaignmanager_swingui/6.
5.0.0/ivy.xml
OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /cygdrive/u/.ssh/identity type -1
debug1: identity file /cygdrive/u/.ssh/id_rsa type -1
debug1: identity file /cygdrive/u/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /cygdrive/u/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: Next authentication method: publickey
debug1: Trying private key: /cygdrive/u/.ssh/identity
debug1: Trying private key: /cygdrive/u/.ssh/id_rsa
debug1: Trying private key: /cygdrive/u/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: Next authentication method: password
[EMAIL PROTECTED]'s password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -p -f /cygdrive/c/temp/ftp/repository/zilliant/p
olicymgt_campaignmanager_swingui/6.5.0.0/ivy.xml
Could not chdir to home directory /cygdrive/u: No such file or directory
Sink: T1195587575 0 1196118721 0
Sending file modes: C0600 1843 ivy.xml
Sink: C0600 1843 ivy.xml
ivy.xml                                       100% 1843     1.8KB/s   00:00
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 1.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

You can see the "T" line above looks like what parseTLine() expects and it has 
the correct last modified timestamp (a Nov. 20 date, more recent than the Nov. 
7 date in the cache). So it seems to me that either that date isn't getting 
down to the "not updated" comparison you pointed out in BasicResolver, or it 
could be the other part of the conditional (!rmr.getDescriptor().isDefault()) 
is evaluating to true. What do you think? Is there something I can check for 
that conditional part?

Chris

> -----Original Message-----
> From: Xavier Hanin [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 21 November, 2007 13:01
> To: ivy-user@incubator.apache.org
> Subject: Re: Problem grabbing updated artifacts
>
> According to the code [1] and your debug trace("not updated"), Ivy finds a
> last modified time stamp in the repository which is older than cache one.
> So
> it seems your problem comes from the SSH repository implementation. Which
> SSH server are you using? Maybe its a problem of incompatibility with the
> library we use... I suggest trying with another SSH server, and maybe also
> trying with a simple filesystem resolver to see if it's related to SSH or
> a
> more general problem.
>
> Xavier
>
> [1]
> https://svn.apache.org/repos/asf/incubator/ivy/core/tags/1.4.1/src/java/fr
> /jayasoft/ivy/resolver/BasicResolver.java
>
> On Nov 21, 2007 7:33 PM, Hilton, Chris <[EMAIL PROTECTED]> wrote:
>
> > > Yes, this is very strange. Which version of Ivy do you use?
> >
> > 1.4.1.
> >
> > Chris
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/

Reply via email to