ftplistparser: no more overwriting set.write_func

[bagder]

The entries in the 'set' struct should remain as set by the application.

[Copilot]

🟡 Changes recommended

The callback-preservation behavior needs targeted regression coverage, and the new API comment is inaccurate.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Moves FTP wildcard LIST parsing into the output dispatch layer, preserving application-configured write settings.

Changes:

• Dynamically selects the FTP list parser during wildcard listing.
• Removes temporary callback backups and restoration.
• Adds wildcard listing-mode detection.

File summaries

File	Description
lib/ftplistparser.h	Declares listing-mode detection.
lib/ftplistparser.c	Implements listing-mode detection.
lib/ftp.c	Stops replacing application write settings.
lib/ftp-int.h	Removes obsolete backup storage.
lib/cw-out.c	Routes listing output to the parser dynamically.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[icing]

So, let me understand what this does.

The application turns on CURLOPT_WILDCARDMATCH and installs callbacks for CURLOPT_CHUNK_BGN_FUNCTION and CURLOPT_CHUNK_END_FUNCTION. Then curl sends a "LIST" command to the server. The response to "LIST" is intercepted by the wildcard parser that matches entries and collects them all.

Once "LIST" is done, , the matching filenames are passed to CURLOPT_CHUNK_BGN_FUNCTION and, depending on its return code, the file is skipped or downloaded and written out through the usual writer callbacks with calling CURLOPT_CHUNK_END_FUNCTION at the end of a download.

Basically, except it's bit more complicated than that since this all happens inside one easy handle who needs to dance its states around...interesting.😰

Hmm...I think FTP should add a new Curl_writer that catches and parses the response from "LIST". Once it is done, it is removed again and the collected list is acted upon. Since the writer is local to the easy handle, any failure will clean it up. And it is not dup'ed either.

More thinking tomorrow.

[bagder]

Basically: yes. And this particular fix is just to stop storing private things in the set.write_func pointer as it meant to only hold the callback set by the application so that duplicate etc always gets the right one and there's no risk that the wrong pointer remains set.