Support commands with responses

[gbrhaz]

I see in the CurlHandle delegate there's a didReceiveResponse method - are there plans to leverage this for commands that take responses? For example, the "SYST" command on an FTP server.

[mikeabdullah]

Hi Harry, I'm not planning anything, but I'm interested to hear more specifically what you want to make use of this for. The challenges to overcome:

1. Parse the header/response — libcurl only hands us the raw text of it, which might happen to cover multiple response codes from the server
2. Figure out a reasonably API for the file manager to expose
3. Handle the equivalent for other protocols than FTP

[gbrhaz]

Well the issue is that a lot of the commands won't be similar for all protocols. Some will be specific to FTP or SFTP, for example.
It sounds like there's a lot involved - more than I realised.
I wanted to use it to get the time for certain files on the server to then work out the time difference between local and server times. There are also other commands that would be useful to get - for example, whether the server is a Windows server.

On a possibly related note - some SFTP clients get the correct working directory that the user would be working on - is this through one of these commands that gives out a response, or a separate one?

[mikeabdullah]

I wanted to use it to get the time for certain files on the server to then work out the time difference between local and server times

When performing a directory listing, you can request that the file's modification date be included in the returned resource properties. Is that good enough? If not, how does it fall short?

some SFTP clients get the correct working directory that the user would be working on - is this through one of these commands that gives out a response, or a separate one?

I'm not too sure on this one how/if libcurl vends that info out. What would you be wanting to make use of it for? Right now, you can happily pass in URLs comprised of a relative path. For FTP and SFTP, that path is resolved relative to the home directory. Doing a directory listing thus enables you to discover the home directory's true path.

[gbrhaz]

The modification date returns the date on the server, rather than the local date for the user - for example, if the server is in a time zone that's +2 hours, and the user creates a file, the user would see the file as +2 hours (in the future).

Perhaps it was just how I was connecting to the server in that case. I was just connecting to the base address, rather than a relative address to the home directory.

[mikeabdullah]

OK, so how would one use the SYST command to handle that time difference?

[gbrhaz]

One wouldn't - SYST is to determine whether the user is connecting to a Windows server (or any other server). 'mtime', 'atime' etc could work though.

[mikeabdullah]

OK, so SYST tells you whether you're connected to a Windows server or not. But how do you then find out the difference in time between the two? I really need some sort of pseudo-code or similar to understand what the heck it is you'd actually like implemented!

[gbrhaz]

Sorry - think some miscommunication going on here.

SYST is to determine what the server is. CK currently doesn't support for Windows servers (which is fine), so it's useful to know without having to parse things.

Getting time difference would be done using MTIME via SFTP. I believe FileZilla uses this same method to check time differences and accounts for it accordingly in the user interface.

[samdeane]

I guess you might be able to use a SITE command to get back a time on some servers. In which case you'd need to be able to parse the results from the command. The trick I've seen for figuring out the timezone it is to make a directory/file, get it back and examine its time, then compare it against your local time to figure out the offset - all of which doesn't need anything special.

[mikeabdullah]

Can you clarify on our lack of support for Windows servers please? I'm aware of one issue, but there might be others, and I'd like to figure it out in the end!

[gbrhaz]

Sorry for the late reply.
@samdeane thanks, that's actually a really good idea.

@mikeabdullah so, the issue is that for some Windows servers, the URLs come back with no resource values. They're all default values or nil. All except the NSURLNameKey value, which has a line of text for all the available data. Actual item name, file size or "

" (if it's a folder), and modified date. At the moment I'm using really basic methods of determining whether the URL is returned from a Windows server. Only problem is, the methods MAY fail at some point, and I'm having to do it on every item that comes back, from any server.

[samdeane]

Sounds to me like that's a problem with parsing windows directories. We have an issue already for FTP - is this a different one @mikeabdullah? The good news is, I think it's on my list of things to try to fix...

[mikeabdullah]

Ah yes, that's the problem I have in mind. By default, Windows FTP servers return results in MS-DOS format, but there is a command that can be sent to switch them over to unix-style. Unfortunately, that command acts as a toggle, so combined with how libcurl manages connections, there's no accurate way to set it!

Ideally then, we write our own parser for Windows-style listings, or find an open source one that can be used. After that, it's a question of whether we query servers to know what type they are, or are able to automatically recognise the listing style that comes back and handle it from there.

[mikeabdullah]

@gbrhaz Out of interest, what "basic methods" are you using to determine this at the moment?

[gbrhaz]

@mikeabdullah I look at a few keys: NSURLFileResourceTypeKey and a few others. NSURLFileResourceTypeKey value comes out as NSURLFileResourceTypeUnknown. So far this has worked fine, but I also put in some quick tests when parsing the name value itself.

[mikeabdullah]

Thanks, that makes sense