2 ms·
The output of ls can be whatever the server wants it to be. djb's publicfile infamously returns a list of files that doesn't look like other servers, which conf
by tedunangst 8y ago
The output of ls can be whatever the server wants it to be. djb's publicfile infamously returns a list of files that doesn't look like other servers, which confuses various clients. (The irony is it was supposed to be easier for machines to parse. But nobody was expecting it.)
- begriffs 8y agoOne factor that mitigates this a little is the "SYST" command. When a client sends it to gitftp, I have it reply with "215 UNIX" to give them a clue about the format. I also browsed a few of the FTP mirrors for OpenBSD and took note of how they formatted their response, and tried to make my format match what I observed to be the most common response. It's worked with all the clients I've tried so far: ncftp on mac, ftp on openbsd, Firefox, mac's ftp-finder integration, and Filezilla. So while there is admittedly ambiguity in FTP servers on the whole, I think my server in particular should work OK. Keeping an open mind though if you know about a problem I haven't foreseen.
- tedunangst 8y agoSo if you're looking at the output from a BSD derived ftpd, a few notes. That used to be just fork and exec "ls -l", and that was slow, so ls.c was copied into src/ftpd. But it's literally the same code. Whatever ls prints, that's what ftpd prints. But the client parsing code is mostly strsep() and cross your fingers and hope to die. It's not terribly robust. Like if you were writing a program, you would not prefer parsing the output of ls to running stat yourself.