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 is ... it depends 😋 It varies between browsers and it’s a bit of a surprise.
Before I show you the screenshots, let me first tell you a short story about how I ended up in the “lets-download-this-file-102-times” rabbit hole so bear with me.
I work as a software developer and one day I got a message from a colleague asking something about a new feature. She sent me a link to an issue. There was a screenshot that caught my attention. It looked very much like the one below.
At the time the file’s name was hardcoded to “Report.zip”. So seeing “Report.zip”, “Report (1).zip” or “Report (42).zip” was to be expected. Instead of a counter, I was suprised to see a timestamp. Where did that come from? It was absolutely not in the code. My colleague didn’t manually add it either. Something was not right. And from here on the rabbit hole got deeper and deeper. 🐰
“A browser setting!” - I thought. It was rulled out quite quickly because she didn’t remember changing any settings. We were looking in Edge because that’s the browser she uses. Besides, such a setting does not exist, I later found out.
“Well, then maybe the browser added it automatically. But at what point?” I started searching on Google, going through different web pages, StackOverflow posts and forums. The more I searched, the more curious I became to figure this out. Then finally - FINALLY - a reply to a Reddit post gave me a pretty strong hint.
But was that still the case? There was only one way to find out. 🚀
Fired up Edge and started downloading.
1, 2, 3, ... 10, ... 42, ... 99 times.
Then something magical 🪄 happened the 102nd time! Instead of bumping a number, Edge added a timestamp 😯 Bingo! 🎉 The mystery was solved. That explained it.
So to make this more scientific, and for the purpose of this post, I decided to repeat the exercise in other browsers. Here are some screenshots.
Edge
Chrome
Firefox
Firefox just continues with bumping the counter. No timestamp here. Also note that there’s no space between the file’s name and the counter in parenthesis, as is the case in Edge/Chrome.
Update 2025-01-14
After publishing this post I got curious about the behaviour in Edge/Chrome. Since both browsers are Chromium-based, which is open source, I could, in theory, just look it up in the code. I didn’t know what to look for. So I asked on Bluesky. Kevin Doyon replied with a link to a method which is responsible for generating a unique filename. Using the “Blame” button at the top of the file revealed where each line of code came from. That led me to this commit which describes why the timestamp is added to the filename.
Seems like this is the end of it. Finally peace 🕊️
What a TIL!
Thanks for reading thus far. Hope you learned something new. See you in another post 😊
P.S. If you want to try it yourself, I’ve prepared a zip with an empty text file. Go ahead and download it. 102 times, of course.
Or you can quickly put together a simple demo by linking to a local file.
<a href="./fancy.zip" download>Download</a>
Top comments (17)
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.