htsname.c appends the mandatory .delayed placeholder extension before it enforces the 236-character path ceiling, and the truncation cuts the tail of the last segment, which is where the marker sits.
The ceiling's comment reserves 12 characters for .99.delayed, but that reserve only sizes the ceiling itself. The last-segment copy is:
for(i = lastSeg; wsave[i] != '\0' && j < maxLen; i++) {
wsave[j++] = wsave[i];
}It stops at maxLen and drops whatever is left, marker included. The other reserve, lastSegSize, is clamped to 12..24 and covers the whole last segment rather than the extension, so any last segment longer than that loses its tail.
IS_DELAYED_EXT() is a plain strendwith_(a, "." DELAYED_EXT), so once the suffix is cut the file stops looking like a placeholder. back_delayed_rename() (htsback.c:1452) then takes its early return, "nothing bound to the placeholder name", and never moves the file to its final name.
The reachable case is the one in #133: deep paths ending in long hashed filenames, which is also where the tail cut is most likely to land mid-name.
Found by code reading while triaging the Windows issues. Not reproduced, so the exact user-visible outcome needs a probe before anyone acts on this. A fix presumably means cutting before the marker is appended, or reserving its length in the copy loop.
htsname.cappends the mandatory.delayedplaceholder extension before it enforces the 236-character path ceiling, and the truncation cuts the tail of the last segment, which is where the marker sits.The ceiling's comment reserves 12 characters for
.99.delayed, but that reserve only sizes the ceiling itself. The last-segment copy is:It stops at
maxLenand drops whatever is left, marker included. The other reserve,lastSegSize, is clamped to 12..24 and covers the whole last segment rather than the extension, so any last segment longer than that loses its tail.IS_DELAYED_EXT()is a plainstrendwith_(a, "." DELAYED_EXT), so once the suffix is cut the file stops looking like a placeholder.back_delayed_rename()(htsback.c:1452) then takes its early return, "nothing bound to the placeholder name", and never moves the file to its final name.The reachable case is the one in #133: deep paths ending in long hashed filenames, which is also where the tail cut is most likely to land mid-name.
Found by code reading while triaging the Windows issues. Not reproduced, so the exact user-visible outcome needs a probe before anyone acts on this. A fix presumably means cutting before the marker is appended, or reserving its length in the copy loop.