curl
                                
                                 curl copied to clipboard
                                
                                    curl copied to clipboard
                            
                            
                            
                        file: implement support for directory listing
~Based on #9745~
This commit implements support to the file:// protocol for directory listings, similar to FTP.
Directory entries are printed as follows:
MODE    SIZE    MTIME    NAME
An example directory listing:
[engler@lennon curl]$ src/curl file:///home/engler
drwxr-xr-x	0	Oct 12 14:09	Desktop
drwxr-xr-x	362	Oct 14 08:31	Downloads
drwxr-xr-x	0	Oct 12 14:09	Templates
drwxr-xr-x	0	Oct 12 14:09	Public
drwxr-xr-x	0	Oct 12 14:09	Documents
drwxr-xr-x	0	Oct 12 14:09	Music
drwxr-xr-x	108	Oct 14 08:34	Pictures
drwxr-xr-x	0	Oct 12 14:09	Videos
drwxr-xr-x	96	Oct 15 17:58	projects
-rw-r--r--	2278067	Oct 13 18:51	wallpaper.jpg
drwxr-xr-x	12	Oct 14 11:21	go
curl FTP file listing works such that it requires an ending slash to trigger it. This ensures that the result is either a file listing or an error (vs. either, depending on the state of the filesystem). It'd be useful to replicate that here as well IMO.
curl FTP file listing works such that it requires an ending slash to trigger it. This ensures that the result is either a file listing or an error (vs. either, depending on the state of the filesystem). It'd be useful to replicate that here as well IMO.
This is a good suggestion. I'll fix that.
What about the targets (like MSVC) that does not have <dirent.h> ?
What about the targets (like MSVC) that does not have
<dirent.h>?
Nothing will happen in these cases. There are preprocessor conditions that check for the existence of fdopendir and <dirent.h>. However, I am unsure if the current way of ignoring is good practice. Maybe fetch_file should be called in that case, just like it happened earlier?
Interesting, opendir(3) works in an unstable way in terms of sorting. Guess I need to implement some sort of sorting.
The fuzzer found problems. This now has merge conflicts.
This PR has conflicts and still has test failures.
Does this patch support --list-only as well? That would simplify one use case I have.
I haven't forgot the PR yet, but I'm currently very busy. It may take until christmas holidays, until I find some free time again :/
Rebased to 99f72c01c214124ee2b18f8c7184215cfc2609c3
Does this patch support --list-only as well? That would simplify one use case I have.
Not yet, but it seems like a good suggestion. I will first try to investigate the CI and fuzzer fails though.