
Have YOU ever tried downloading the same file 102+ times in your favorite browser? Do you know what happens on the 102nd time? 🙃
I do. The answer ...
For further actions, you may consider blocking this person and/or reporting abuse
I dug a bit deeper into why Chromium acts this way.
Apparently, Chromium checks
IsPathInUse()
for each file path. So it checks ifnote.txt
exists; if so, then check fornote (1).txt
, etc.To cap the number of operations, they historically set the max # of unique files to 100 hoping it would be enough. But in 2012, someone reported a bug that they couldn’t download more than 100 files with the same name 😂
It took 8 years for folks to prioritize this (when they realized Android downloads were just silently failing).
Interestingly: If the name + timestamp file path already exists, Chromium still gives up. On desktop, it prompts to name the file; on Android, the download fails silently!
Wow! Thank you @sesh_sadasivam_8513689617 for looking this up. Great detective work 🕵️
Funny enough, I also tried digging into this. I just updated the post with my findings and noticed your comment. Apparently we both ended up in the same commit 😊 but you've done much better job describing the reason for this behaviour. Thank you again 🙏
Any explanation for this behavior?
It will be fun to actually see it in the code. Maybe there's an explanation. But I have no idea where to look and what to look for.
So my simple explanation for now is for finding the file more easily by looking at the timestamp. The counter doesn't give much information.
I will try to look for it on a open source browser.
Switching methods seems like overengineering. I wonder whether this was informed by UX tests?
Will need to get to the bottom of this. Will try asking people on Bluesky. Hopefully someone knows/can point me to a direction 🙂
Asked on Bluesky and got a reply with links to GitHub. After some digging, it seems like the file download failed [silently] at 100 on Android, so the timestamp was added as a fallback.
github.com/chromium/chromium/commi...
To state the obvious, this applies if files with the same name (and the parenthetical numbering) exist in the default save location, regardless of whether or not you actually downloaded the exact same file (or any files at all) 100+ times
You're right @geekahedron
How the file ended up in the save location doesn't matter. It could've been copy/pasted 100 times and downloaded only once. Or it could've come from different web pages. The important part is that it has the same name. But I've constrained the post to the assumption that the file is downloaded 100+ times because that was my use case.
Thanks again for the clarification :)
It seems like you're the Sherlock Holmes of IT hahaha.
Haha I find it exciting to get to the bottom of these things in order to understand the reason for their behaviour. There are for sure many people who also like to do that but not many share their findings in blog posts. That's why you can find a lot of these weird browser quirks, small workarounds, etc buried in forums or answers to StackOverflow questions.
If you like these kind of posts, I also got another one I wrote a while ago 🙂
Debugging layout repaint issues triggered by CSS Transition
Dzhavat Ushev ・ Feb 18 '21
The timestamp was added the 101st time. Why do keep referring to the 102nd time? 🤔
first time is "filename", second time is "filename(1)"
So essentially it becomes 0 indexed, similar to an array, so the 101st item is "filename(100)" and the 102nd item would be "filename(101)" if the numbering continued.
OP is correct!
Thanks for the clarification @grahamthedev :)
Oh. Thanks for pointing that out
No problem, I had the same thought at first! Haha.