TortoiseSVN/TortoiseGIT文件和文件夹或图标不显示问题解决方法

爱被打了一巴掌 2023-02-27 05:43 31阅读 0赞

最近发现自己电脑上的TortoiseGIT图标不显示，在网上查了些方法，试过之后都不行，最终是需要在TortoiseGIT下的setting中做相关的设置才可以正常显示，在这里做一个简单的记录，以供参考。

步骤如下：

1. 打开Tortoise的Settings- Icon Overlays - Overlay Handlers - Start registry editor

此步确定Tortoise系统排在前面（方法为重命名，在名字之前添加空格/数字等都可以实现）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pvaG5aaG9uZ0pvYg_size_16_color_FFFFFF_t_70][]

2. 在Icon Overlays中将Status cache设置为 Shell, Drive Types设置为Fixed drivers, 最下面的Show excluded folders as normal勾选上

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pvaG5aaG9uZ0pvYg_size_16_color_FFFFFF_t_70 1][]

重新启动Windows资源管理器(或者重启电脑)，图标正常显示。

///

// [https://devblogs.microsoft.com/oldnewthing/20190313-00/?p=101094][https_devblogs.microsoft.com_oldnewthing_20190313-00_p_101094]

# Why is there a limit of 15 shell icon overlays? #

There is a limit of fifteen shell icon overlays. Why fifteen?

The value 15 came from the corresponding limit for image lists. The [`ImageList_SetOverlayImage`][Image_List_Set_Overlay_Image] function supports up to 15 image list overlays per image list. (Hey, it used to be worse. The limit used to be only 3!)

Okay, but why only 15? Why not more?

The overlay image is one of the pieces of information used when drawing an image from an image list. The options are encoded in the `fStyle` parameter, and when the bits were divided up for various purposes, four bits were available to be used to specify the overlay image. (You get 15 overlay images instead of 16 because you lose one of the values in order to specify “no overlay.”)

Okay, but the values in the `fStyle` parameter use only the bottom 16 bits. What about the upper 16 bits? There’s plenty of room there.

The 16-bit limit was carried over from the 16-bit version of the common controls (which still needed to be supported in Windows 95). Of course, nowadays, nobody cares about the 16-bit version of the common controls, so why not start using the upper bits?

There’s an unsatisfying explanation: The code internally that manages the `fStyle` still uses a `WORD` in some places, so all the code that manages the `fStyle` would have to be revised. This occurs in multiple modules across Windows, so a synchronized change would have to be made across multiple components. This is a breaking change at the binary level because the interfaces are no longer compatible. Breaking changes are procedurally difficult to coordinate: The affected code may not be visible to the shell team because they are [sitting in a far-away leaf branch][] that has not yet RI’d to the trunk. It might be that expanding `fStyle` from a `WORD` to a `DWORD` has far-reaching consequences for some component.

Like I said, this is unsatisfying. Basically it boils down to “It would be a lot of work and we are lazy.”

Another unsatisfying explanation is that the image list serialization format would be affected. This is one of the far-reaching consequences I hinted at: Changing a file format means that you also need to come up with a compatibility story. What happens if an old program encounters a file in the new format?

Okay, so maybe we leave image lists the way they are, but change Explorer so that it internally allows more than 15 overlays by, say, “paging” overlays in and out of the system image list. But this would require taking a lock during image list drawing operations, which currently can be performed concurrently. But the system image list is exposed to applications so that they can draw out of them directly, and applications won’t know about the extra serialization that applies only to the system image list. So that’s a non-starter, too.

A bigger problem is that the overlay indices are exposed to applications via the `SHGetFileInfo` function. If you ask for `SHGFI_OVERLAYINDEX`, then the function returns the overlay index to the application, and if the overlay index is greater than 15, older applications won’t know how to draw with it.

Now, these problems aren’t completely insurmountable. For example, we could invent a new flag to `SHGetFileInfo` that says, “I understand overlays greater than 15,” and if the caller doesn’t set the flag, then the function just pretends that those overlays don’t exist. The calling application doesn’t draw the icon correctly (it’s missing the overlay), but at least it doesn’t crash.

But the main reason this doesn’t get done is simply that overlays are [not recommended as the way to convey metadata about a file to the user][]. An icon can have only one overlay, which means that if multiple overlays apply, then the system will arbitrarily choose one to show, and the others will lose.

Windows 10 takes a step away from icon overlays by moving the OneDrive file synchronization status indicator from an icon overlay to a separate *Status* column.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2F5YW5nMTk4Ng_size_16_color_FFFFFF_t_70][]

Since it’s a separate column, there’s room to put more than one status icon there.

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pvaG5aaG9uZ0pvYg_size_16_color_FFFFFF_t_70]: /images/20230209/ace3715afb2449a29d747876e233759b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pvaG5aaG9uZ0pvYg_size_16_color_FFFFFF_t_70 1]: /images/20230209/bf208f486423412f8254d57d777e8dc5.png
[https_devblogs.microsoft.com_oldnewthing_20190313-00_p_101094]: https://devblogs.microsoft.com/oldnewthing/20190313-00/?p=101094
[Image_List_Set_Overlay_Image]: http://msdn.microsoft.com/library/bb775227
[sitting in a far-away leaf branch]: http://blogs.msdn.com/b/oldnewthing/archive/2013/08/20/10442834.aspx
[not recommended as the way to convey metadata about a file to the user]: https://blogs.msdn.microsoft.com/oldnewthing/20091209-00/?p=15723
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2F5YW5nMTk4Ng_size_16_color_FFFFFF_t_70]: /images/20230209/471f926d8e28498da82f7f4395a45c59.png