Problem with SFTP copies

[pscs]

Take Command v25.00.20 x64

I'm not sure if this one is user error or not, but, if so, it seems inconsistent

Following on from my FTP copy problem (my previous post), I tried using SFTP instead. The server is set up support that as well.

TCC seems to add '/*' onto my SFTP path, which then fails

I can't work out how to copy an individual file using SFTP

If I use "copy /b "sftp://testuser:testpass@testserver.pscs.co.uk/home/testuser/" then it copies the whole directory contents OK, but that's not what I want to do...

 

[rconn]

I verified the SFTP issue here; it's a problem with an ipworks api.

TCC tries to determine if the name is a directory, and if so it adds a "/*". The directory test consists of attempting to change the default directory to the specified name and checking the error return. As an extra check, TCC then queries the current directory to see if it matches. The problem with the ipworks dll is that it not only says the directory change to …/file1.dat succeeded, but that the current directory is now …/file1.dat.

The FTP and FTPS apis do not have this problem. I filed a report with ipworks; in the meantime I'm trying to find a workaround for SSH.

 

[pscs]

Ah! We're using IPWorks here as well and ran into a similar problem - what we do is the other way around to what you're doing: try to copy the specified file. If that doesn't work, then assume it's a directory and try that.

 

[rconn]

Pending a permanent fix, you can do something like:

copy /b "sftp://testuser:testpass@testserver.pscs.co.uk/home/testuser/file1.dat*" z:

TCC knows that if the name has a wildcard it can't be a directory. (Of course, if you have multiple files that match the wildcard spec, you'll get multiple downloads.)

 

[Charles Dye]

Pending a permanent fix, you can do something like:

copy /b "sftp://testuser:testpass@testserver.pscs.co.uk/home/testuser/file1.dat*" z:

TCC knows that if the name has a wildcard it can't be a directory. (Of course, if you have multiple files that match the wildcard spec, you'll get multiple downloads.)

How about if you

copy /b "sftp://testuser:testpass@testserver.pscs.co.uk/home/testuser/file1.da[t]" z:

Does your wildcard test recognize that as a wildcard? Or does it only recognize asterisks and question marks?

 

[rconn]

With extended wildcard characters, TCC has to look first for an exact match, since [ and ] are valid Windows filename characters. The exact match test will result in a bogus directory name match.

 

[AnrDaemon]

Ah! We're using IPWorks here as well and ran into a similar problem - what we do is the other way around to what you're doing: try to copy the specified file. If that doesn't work, then assume it's a directory and try that.

I'd say, that even after ipworks fixes their hickup, this is a more straightforward resolution to the original question of figuring out, if target is a directory.

 

[rconn]

I'd say, that even after ipworks fixes their hickup, this is a more straightforward resolution to the original question of figuring out, if target is a directory.

Yes, provided it's a small file.