bisecting between version-2.27 and current tip of trunk points to 6ce705b8dcfeca4f as the 'culprit', ee445feef78a265a is still good.

and bisecting along that branch (timeline-enhance-2025) points to 3d63613a7e7afac5 as first commit, that shows the problem. The one before 58a99696748c0ea8 is fine. Something wrong inside archive_base_name(rid) ?

/vinfo/hash segfaults as well.

To reproduce:

fossil init X.fsl
fossil open X.fsl
echo x>x.txt
fossil add x.txt
fossil commit -m x
fossil ui

It does not occur on a fossil proper repo. Maybe some settings missing on an fresh repo?

yes. goes away if project-name is set.

so something is probably wrong in the reading of project-name / short-project-name in archive_base_name (tar.c)

Summary and proposed fix:

On a fresh repository with

• at least one commit after initial commit
• not project-name set yet
• with rights to view/downloads zip/tar/...
• => so pretty much the standard for a new repository an the first fossil ui on it !

there is a problem under certain OS / (maybe hardenend) libc in the function archive_base_name(rid) from src/tar.c because the SQL there returns 0 rows when project-name is not set.

It looks like the LEFT JOIN config and the last part of the WHERE are not needed at all (nothing from the config table is used in the select), the project-name/short-project-name with default "unnamed" is dealed with in the preceeding lines.

And indeed, the following simple patch fixes (and simplifies) it:

Index: src/tar.c
==================================================================
--- src/tar.c
+++ src/tar.c
@@ -77,14 +77,13 @@
   }
   zName = db_text(0,
     "SELECT %Q||"
           " strftime('-%%Y%%m%%d%%H%%M%%S-',event.mtime)||"
           " substr(blob.uuid,1,10)"
-     " FROM blob, event LEFT JOIN config"
+     " FROM blob, event"
     " WHERE blob.rid=%d"
-      " AND event.objid=%d"
-      " AND config.name='project-name'",
+      " AND event.objid=%d",
     zPrefix, rid, rid);
   fossil_free(zPrefix);
   sanitize_name(zName);
   return zName;
 }

Summary and proposed fix

Thank you for that. We'll get this fixed. i'd like to double-check that there's not another way to solve this, but i agree completely with your patch as-is.

Edit: Richard has already checked it in.