Filename too long - Warning: Failed to create the file #2174

Closed
badaniem opened this Issue Dec 12, 2017 · 7 comments

Comments

Projects
None yet
4 participants

I did this

curl -O -J
"http://example.com/test?somelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelon
gargumentlistsomelongargumentlistsomelongargumentlistsomelongarg"

and got
Warning: Failed to create the file
and than
curl: (23) Failed writing body (0 != 1270)

I expected the following

File
"test?somelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomelon
gargumentlistsomelongargumentlistsomelongargumentlistsomelongarg"
will be created in current directory but it's not the case because filename is > 255 bytes.

If curl cannot create file because name is too long than I expect file with trimmed name to be created.

curl/libcurl version

curl 7.56.1 (x86_64-pc-linux-gnu) libcurl/7.56.1

operating system

4.13.12-1-ARCH x86_64 GNU/Linux
Filesystem: ext4

Owner

jay commented Dec 12, 2017

I'm not for this. If you are not sure that the server will provide the filename and you have a query like that I would use --output instead

@bagder bagder added the cmdline tool label Dec 12, 2017

Owner

bagder commented Dec 12, 2017

I agree with @jay. -O is about using the name from the URL as file name as that makes the client side absolutely sure what file name that will be used. Trimming it changes that and opens up a risk for overwriting files that were not meant to overwrite.

If possible, the error message could be clearer.

Owner

bagder commented Dec 12, 2017

The error message shown above was shortemed, wasn't it?

The code already uses strerror() which should at least include some clue about the specific reason for the failure. I would presume the errno would be ENAMETOOLONG or something on Linux.

badaniem commented Dec 12, 2017

Shortened? Not really, full output:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                             Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
Warning: Failed to create the file 
Warning: test?somelongargumentlistsomelongargumentlistsomelongargumentlistsomel
Warning: ongargumentlistsomelongargumentlistsomelongargumentlistsomelongargumen
Warning: tlistsomelongargumentlistsomelongargumentlistsomelongargumentlistsomel
100  1270  100  1270    0     0   1270      0  0:00:01 --:--:--  0:00:01  3082
curl: (23) Failed writing body (0 != 1270)

error code = 23

I'm using curl as a download tool for custom webkit-based browser (surf).

Option -J is necessary to have proper filenames for downloadable *zip, *pdf, etc. On the other hand I could trim filename by myself (in surf c code), but in such case I loose -J Content-Disposition filename because -o is apparently superior to -J.

So other expected solution would be:

curl -J -o "my-filename" "http://..."

but to make -o "my-filename" work only if Content-Disposition is not in the headers.

bagder added a commit that referenced this issue Dec 12, 2017

Owner

bagder commented Dec 12, 2017

Aaah, the warning message itself is truncated as it only uses a 256 bytes buffer so the error message after the file name isn't visible! I'll start out by fixing that... (commit 5d0ba70)

because -o is apparently superior to -J.

Yes, -J only works with -O. I suppose it could be expanded to also work with -o, but that would mean new functionality.

So really, with a >255 bytes long part to the right of the rightmost slash, -O is doomed to fail and there's not a lot we can do about it.

If you have trouble with file name, try trimming it with programs like Long Path Tool.

Owner

bagder commented Jan 24, 2018

I think curl is doing the right thing here. It tries to use the name as instructed, and when it fails is tells the user why. With the landed fix, it should now display it even with very long file names in the message.

@bagder bagder closed this Jan 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment