Firefox will open save to, with the filename like '14e32a132f8a40ba.chm'

Can you please confirm this with another browser? You're the first to report this so far and the attachments support has not, to the best of my recollection, been modified in years. (The very recent wiki editor additions for listing attachments did not touch any of the existing attachments code.)

Tried with 'Edge'.

• Attaching new pdf & exe & ini then download
  
• Download 'old' ttachments
  

Edge save them named Artifact-name without extension.

example: 69e2e8897a49a520

Edge save them named Artifact-name without extension.

And Chrome on Linux is doing something completely different for me.

As a point of reference, i'm downloading from:

src:/attachlist

Those all download as expected for me when following the "download" link next to each one:

[stephan@nuc:~/Downloads]$ ls -la
...
-rw-rw-r--  1 stephan stephan        900 Aug 18 19:52 Windows-case-sensitivity.bat
-rw-rw-r--  1 stephan stephan        652 Aug 18 19:52 fossil-6dba56543b89dc41-1.patch
-rw-rw-r--  1 stephan stephan       1744 Aug 18 19:50 fossil-uuid-override.patch
...

However, if i run the page locally it is behaving differently: some download links simply take me back to the home page without doing anything and some download as expected. That seems to be (unverified) a caching issue.

How are you downloading these? If you're going through the Raw==>Download links, what you're seeing is expected. For example:

src:/ainfo/330a39312cb4c7b7 then "Raw" (near the top of the page), then "Download" will result in it downloading with the artifact name, and that's the expected behaviour from those links. Where that mysterious "chm" extension comes from is anyone's guess, though - fossil isn't adding that.

Going through the attachlist page for a wiki wiki page, e.g. /attachlist?page=TheWikiPage offers a link to download using the expected name. The links at the bottom of the wiki viewer go through a path which uses the artifact ID as the name.

To the best of my knowledge that behaviour hasn't been changed in ages, but it doesn't seem particularly friendly. i'll take a look at what's needed to get those particular links to download using the expected name (with the caveat that those names might not be legal for the downloader's filesystem (which might be the historical reason that it currently behaves the way it does)).

i'll take a look at what's needed to get those particular links to download using the expected name (with the caveat that those names might not be legal for the downloader's filesystem (which might be the historical reason that it currently behaves the way it does)).

As a partial/quick workaround...

Rather than change the historical behaviour, the "Attachments:" heading at the bottom of wiki pages which have attachments now links to the /attachlist page, which lists the same attachments but offers a "download" link which downloads using the stored filename instead of the artifact ID.

The longer-term fix is probably to modify the attachment list to include such links directly (alongside the historical ones), but i'll need to look at and test that change more thoroughly, as it would affect tickets, tech-notes, and wiki pages.

The longer-term fix is probably to modify the attachment list to include such links directly (alongside the historical ones), but i'll need to look at and test that change more thoroughly, as it would affect tickets, tech-notes, and wiki pages.

The attachment lists in those contexts now include a [download] link, like the one on the /attachlist page, which attempts to download using the given filename. One caveat is that its handling of non-existing attachments is less than ideal. It will respond with a 302 ("moved temporarily") and redirect to the home page, which is a bit confusing but probably doesn't affect most repos. (Fossil's core repo has many attachment "corpses" left over from its early days when anonymous users could attach stuff to tickets.)

One lingering problem we have with downloads, but i'm not certain how best to fix, is that it will "url-ize" filenames, leading to spaces in the filenames getting replaced by +, and the downloaded filenames include those + characters. That's not a new behaviour, just something which stuck out while testing with such a file.

What is wrong? What do you expect to happen?

expected the file download with it's original name.

Has this always been like this? Using attachments for three years and I've never noticed. Thank you for this information.

For tickets, it looks like the attachments are based on the artifact ID. I uploaded a text file to a new repo and new ticket. When downloading it wants to save as 5a282c56aeb16813, without any file extension.

The same looks true for a new wiki page. I can see the contents of the (new, different) text file, but when trying to download, it wants to save as the artifact ID.

I'm using Windows 10 with Firefox 91.0.

Update:

Tried with 2.10 on the not rebuilt backup of repo:

To wiki pages attached downloads will be linked as:

http://fossil-host/raw/name+of+file.pdf?name=a1b6433f9747166d089a2029966ac2f6786fd647aac0e18ae5c4f31be02642af

On download request, the filename will therefore persist.

As on 2.16:

http://fossil-host/raw/83602af8757571d2c58c0b4dd47b9234505a21073c06a197dbaa59a99c80cffa?at=83602af8757571d2

Consequently donwloads will named by artifact id.
(The chm ending addition is likely a bug from Firefox)

There really seems to have been in change in creating the download link, now missing the name-+of+file.pdf.

As on 2.16:

Thank you for tracking that down. Before changing that back i'll need to investigate why it was changed. i suspect, but don't know for sure, that someone ran into a problem where the file's real name was not valid on a specific system and thus could not be downloaded, so the change was made to use the artifact IDs. That's just speculation but that problem is certainly feasible.

Yesterday i checked in a change which adds [download] links next to each filename in the list of attachments at the bottom of wikis/technotes/tickets, and the older links were retained. Tapping on the attachment's name takes the user to the artifact detail page and tapping the new [download] link will attempt to download using the file's preferred name (assuming that it's legal for the user's system). That change should, i think, resolve your immediate problem but will require that you either build from trunk or wait an indeterminate amount of time until the 2.17 release. In addition to that change i'll look at adding similar download links on the artifact pages for the attachments.