Keep attached file name intact while downloading
When a user downloads an attachment, the file name seen in the post is replaced with some generated (hashed?) name which forces user to rename the file. It would be desirable to keep the original file name intact during download.
- 6 replies
Ok yes this is a bit annoying to me too. I'd like to fix this. The files are hashed, because then 1) if different people upload the same file, no additional disk space will get used. And 2) when downloading, even if files were uploaded using different names, they'll get the same hash and will get cached by the CDN (if a CDN is in use).
There's a new HTML5
download=attribute that works like so:
<a href="path-to-file" download="name-to-give-to-saved-file.txt">...<a>(see this StackOverflow answer) that lets one specify the name of the file name after download — but seems it won't work together with a CDN, because requires the same origin. (Hmm maybe there's some way around this)
Anyway, in your case (on-premise), I suppose there is no CDN. Also, maybe most people won't setup a CDN. So maybe downloading files, using their original names, should be the default behavior. And there could be a config option, to enable the hash name optimization.
(On the disk, they could be saved using hashes though, that'd cause no problems.)
Fixing this is a little bit tricky: I'll need a table that maps file names, to file hashes, and maybe review some reference counting code (that tracks how many times each uploaded file, is linked / used — when the ref counts gets 0 they're supposed to get auto deleted). So probably this will have to wait for a while.
Hmm I suppose I can add the HTML5
download=...attribute, always, and then it ought to work, for you since you don't use any CDN. I'll give this a try.
- Progresswith doing this idea
- @KajMagnus marked this topic as Planned 2018-08-11 08:38:34.114Z.
I've fixed this in a GitHub branch now, by adding the
download=...attribute. So your files will have the same name, when downloaded, as when uploaded. The fix will be included in the next release, in maybe 5 days. (And works only when no CDN is in use.)