Gosh... making this based on the used icon is quite bad (existing code I mean, not your fault!), let's move away from that. Pretty sure this could just check the extension of wmDrag.path. There is BLO_has_bfile_extension(), but that doesn't cover backup .blends. For that file_is_blend_backup() could be moved to BLO.

Alternatively if we stick to the drag based icon (may be safer for 3.0), we can make sure to always pass ICON_FILE_BLEND to UI_but_drag_set_image() in file_draw_preview(), by calling filelist_geticon() again with is_main = true and pass that to .

I ended up committing the icon based fix for the 3.0 branch (crediting you as author).

Two notes:

• I removed the backup file support again, since at this point in the release cycle such functional changes shouldn't be done. Even if that trivial.
• Checking on how to best solve this longer term, I decided this should be properly handled by the drag and drop code, not just ad-hoc for this case. So created a patch to refactor all cases that use icon based drag & drop logic: D13428: UI: Refactor path dropping so logic doesn't depend on icons

Just to reply to the previous comment (even though it doesn't matter for this anymore):

In D13383#353208, @Harley Acheson (harley) wrote:

The weird thing about this one is that existing file_is_blend_backup returns true on regular blend files too. I don't mind this behavior as much when it is private, but seems weird as a public function. I added a comment about that in this patch though.

We could do two things in such a case, both fine with me:

• Change the function name to reflect that, e.g. BLO_has_bfile_or_bfile_backup_extension().
• Call BLO_has_bfile_extension() in the beginning of the function and early-exit with false if that is true. Some code paths may end up calling it multiple times, but I don't think that's an issue (and branch prediction might even optimize it away).

In D13383#354663, @Julian Eisel (Severin) wrote:

Just to reply to the previous comment (even though it doesn't matter for this anymore):

In D13383#353208, @Harley Acheson (harley) wrote:

The weird thing about this one is that existing file_is_blend_backup returns true on regular blend files too. I don't mind this behavior as much when it is private, but seems weird as a public function. I added a comment about that in this patch though.

We could do two things in such a case, both fine with me:

• Change the function name to reflect that, e.g. BLO_has_bfile_or_bfile_backup_extension().
• Call BLO_has_bfile_extension() in the beginning of the function and early-exit with false if that is true. Some code paths may end up calling it multiple times, but I don't think that's an issue (and branch prediction might even optimize it away).

It can be replace with a one-liner:

/* Return true for .blend1, .blend23, .blend102, etc. */
static bool file_is_blend_backup(const char *str)
{
  return (!BLO_has_bfile_extension(str) && BLI_strcasestr(BLI_path_extension(str), ".blend"));
}