Files with the same name sometimes end up with the wrong icon

[UndefinedOffset]

Using atom 1.12.8 and file icons 2.0.7 it looks like when two files are named the same with different extensions they can get the wrong icon. See screenshot, the files in it are a mix of .feature and .yml files it doesn't appear to happen to all files just some. So the duplicate name may not be the root of the issue.

[Alhadis]

Eh? Bizarre. Do the .feature files which show database-icons contain modelines or anything? Something that looks like this?

-*- yaml -*-

[UndefinedOffset]

They do not appear to, the two files in the above example that you can't see the extension on and have the database icons are event-calendar-panel.feature and event-calendar-panel.yml. The event-calendar-panel.feature does have reference to a .yml file in it but there are other files not affected that have this same thing. I also just noticed another bizarre behavior when you open one of the affected files the icons change on a bunch of files to incorrect icons. For example opening the event-calendar-panel.feature when it's icon is the database icon the event-calendar-panel.yml changes to the yaml icon as does a bunch of other files not affected. It also happens in reverse too though opening the yaml file fixes the ones that opening the feature file changes. A very strange issue lol.

I was also seeing some files with the same name as a folder and having an extension getting a folder icon and wouldn't open properly causing no tab to appear in the window. But either the update to 2.0.7 for file icons or the update of Atom itself to 1.12.8 appears to have corrected that one.

[UndefinedOffset]

I should probably also mention I noticed this is a Windows 10 system, if it matters ;)

[Alhadis]

Could I convince you to send me that folder so I can inspect this on my end, or is that too much trouble?

I was also seeing some files with the same name as a folder and having an extension getting a folder icon and wouldn't open properly causing no tab to appear in the window. But either the update to 2.0.7 for file icons or the update of Atom itself to 1.12.8 appears to have corrected that one.

No, I fixed that issue with the most recent patch.

[UndefinedOffset]

Unfortunately due to the confidentiality of the project the files pertain to I'm not sure, I'll ask around and see what some of the others think.

[DanBrooker]

Are you able to replicate the bug with some non confidential files?

[UndefinedOffset]

Let me see if I can slap something together later today

[UndefinedOffset]

Here's a zip of some files that produce it, I've stripped them down to next to nothing in them but it produces the issue. At least some of the time. I have noticed though that after editing the files, then reverting them in via git it seems to have fixed the problem for the affected files. So maybe that is the key? It's a strange issue anyways :S.
issue-499.zip

[Alhadis]

... then reverting them in via git it seems to have fixed the problem for the affected files. So maybe that is the key?

We currently have no way to track changes that happen to files outside Atom. This is something I intend to fix in a future release, but it's also not something to be taken lightly. Monitoring too many files for changes can risk blowing the process's ulimit, which basically determines how many file descriptors any process can have open at a given time.

I can't see or reproduce anything unusual with these files... :\ I may need to add some package commands to generate diagnostics, because I can't keep pestering you guys with aimless questions..

[Hendrik]

A similar issue happened to me yesterday, where newly created folders & files would end up with a wrong icon and it wasn't possible to open those files in the editor, as it would just switch to an empty tab with no name or switch to the previous open tab when I clicked on the file.

However, this issue appeared to be completely random, as it would happen maybe 4 out of 10 times when creating a new file through the editor's tree view or directly from the command line. The only common thing was that all the broken files & folders were using the same icon, which looked similar to the default Windows 10 folder icon (a 90deg rotated version of the actual folder icon).

I'll try to provide some images & further details, if it happens again.

[ralphbens]

I don't know if it might be of any help, but on file-icons 2.0.14 I'm getting this behavior:

1. Create a new folder with any name (say folder)
2. Delete that folder
3. Create a new file with the same name on the same path (folder, without an extension)
4. It'll show up with a folder icon rather than the intended icon.

This doesn't happen the other way around (first create the file, delete, then the folder).
Extensions do matter; if you create a folder, delete, then create a file called folder.rb, it'll work fine.

Something to do with caching the icons?

[Alhadis]

Well picked up!

You're right; the caching is done using the whole path, so if the folder you created was named folder.rb, you'd get the same result.

Note that collapsing and reopening the containing directory in tree-view will actually refresh the icon.

Will fix; track #490 for updates.

[UndefinedOffset]

So here's a new one to throw into this, it doesn't appear to just be the same file name. I have three files in a folder:

• external-content-support.feature
• external-content-support.yml
• test-page.html

The last two have the html5 icon, as well in another folder there's two files with the same name but different extensions one of them has a folder icon. When it's opened it doesn't create a tab. Is it possible there's some kind of memory/index collision happening? Collapsing and re-opening folders doesn't seem to change anything.

As well one folder "settings" is getting an icon that looks like switches (probably because of it's name) when you leave a file inside of it open and restart atom.

[Alhadis]

@UndefinedOffset Open devtools, and run this in the console:

_FileIcons.fs.FileSystem.paths

You should be presented with a Map of system paths keyed to filesystem resources (a File or Directory). Can you see any strange-looking keys that point to the same file, or to invalid values? Any keys with inconsistent path separators, or incomplete paths?

As well one folder "settings" is getting an icon that looks like switches (probably because of it's name) when you leave a file inside of it open and restart atom.

A folder named "settings", you mean? Did another file of that name exist in that location previously? FYI, the switches-icon is intentional: it's a "best guess"-type pattern which is used when nothing else matches (so a more appropriate icon than a blank page can be picked).

[UndefinedOffset]

So this is interesting using the command you suggested running in the console has some interesting keys most are either a File or Directory but some are undefined incidentally these one's have the wrong icon. In the case of the form-panel.yml and video-hero-panel.yml their .feature counterparts are missing from the map. In the case of test-page.html it there is no file named similarly. As for the main-navigation.feature flagged as a directory I'm not sure what's going on there there could have been at one time a folder called main-navigation but if there was it's been gone for awhile. The paths look fine, though it does switch between the windows \ and unix / but normally that doesn't cause issues in most other programs.

In the case of the folder named "settings" when leaving a file inside of it opened and restarting atom it's also flagged as undefined with the two children keys 0 and 1 (see below, I cut out some non-applicable files/directories from the image)

So maybe the undefined is a clue as to the issue, also there are no errors in the console when either issue happens.

[Alhadis]

Pretty much falls in line with #563. If you read the discussion there you'll see that stuff will become less flaky once a few tree-view PRs are merged and shipped.

In other words, it's a known issue.

[adamreisnz]

Any news on this issue?

I notice it mostly when I accidentally create a new file instead of a folder, and then remove it and create a folder with the same name:

[Alhadis]

Just tell me if it's possible to install Ubuntu on a 2 TB external hard-drive that I can install and run Atom on, because I haven't been very lucky compiling Electron/Atom on OpenBSD yet. 😜 Suffice to say these issues are known to me, but state of available hardware is making everything hard.

[adamreisnz]

Not sure I follow... you are working on an Atom plugin, but you are unable to run Atom on your machine? 😄

My problem is on OS X, if it helps.

[Alhadis]

To cut a long story very short: my MacBook died late last November/early December, leaving me with a bulky old dell running OpenBSD.

Since I'm too penniless to afford a new computer, everything Atom-related that isn't urgent has been forced onto the backburner until I can figure out how to build the thing on this system. Everything Atom-related that HAS been urgent has involved a song-and-dance routine of borrowing computers, running around with USB sticks in my pocket containing various SSH keys, and basically not exactly succeeding at life much lately. 😁

[adamreisnz]

Heh, that does explain!
Let me know where the new laptop donation fund is and I'll see if I can help 😄