Error in renaming folders [FIXED]

[sasha]

In Version 1.1.5 build 1812, renaming folders using either Ctrl+F6 or Shift+F6 doesn't work for me properly. After renaming, the folder keeps his old name in the panel, although the new name can be seen in the overlapping Terminal or in Finder. Changing folders doesn't seem to have an effect. The new name is visible after restarting NC. Renaming files works fine.

[mike]

Sasha, can you provide me with some more details?
I can't reproduce this behavior.

BTW, is there any chance, that you're renaming a bundle directory and "Show localized filenames" option is turned on?

[sasha]

You're right, regular folders aren't affected. The error seems only to occur with bundles and "Show localized filenames" turned on.

Here's a quick screen cast: https://vid.me/RG8q

Renaming regular folder works fine. Renaming the bundle (in this case Omnigraffle) doesn't change the name displayed in the panel, although it's changed in the Overlapped Terminal and in Finder. The new name is only displayed after restarting NC.

Turing "Show localized filenames" off solves it, but I would like the setting to remain on.

[mike]

Right, what seems to appear as a bug is in fact a highly optimized non-updating cache

Here's the explanation:
In short - asking the system to provide a so-called "display name" (aka localized filenames) for every entry on every directory listing fetching is slow.
And users of NC likes it for swiftness, so I wrote a caching facility with some assumptions in mind:
- localized display names are generally made from Info.plist's regarding current user's language setting.
- neither of previous two seems to be changing at all, so any state checking on a consequent display names retrieval would be wasting of resources (and I want to keep the CPU cold).
So currently that display name is built only a single time for a (dev,inode) pair and any later requests are fulfilled with initial result.

This behavior can be made more intelligent, but this will cost some additional I/O and frankly I don't think this is important.

[sasha]

Right, what seems to appear as a bug is in fact a highly optimized non-updating cache

Thanks for the explanation, Mike. Always interesting to see how things work under the hood.

If the bundle is renamed in the file system but the old name is displayed to the user until restart of the program, this still qualifies to me as a bug. This one is just mildly annoying to me, really no big deal. But as form should follow function, I think displaying correct information to the user is more important than performance and worth the overhead.

Keep up the great work, Mike!

[mike]

Ok, I got your point.
Will try to do something about it.
The problem is that the behavior of this "display names" generation is not documented at all, and it's absolutely unclear what data effects it.

[mike]

Just for record: fixed, will be available in next preview build.