Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files fail to refresh icons after deletion and recreation #490

Closed
benderTheCrime opened this issue Jan 3, 2017 · 9 comments · Fixed by #693
Closed

Files fail to refresh icons after deletion and recreation #490

benderTheCrime opened this issue Jan 3, 2017 · 9 comments · Fixed by #693
Assignees
Labels
atom-fs Filesystem-related issues to address when developing a stable release of the `atom-fs` module. bug Confirmed defect in package logic, deprecation notices, and PRs which fix them.

Comments

@benderTheCrime
Copy link

This is a weird issue, but I noticed that a file failed to automatically refresh it's icon when it was deleted and then recreated.

Atom Version

1.12.7

Steps to reproduce

  • create a FOLDER called index.js and observe that it correctly has a folder icon.
  • delete the index.js folder
  • recreate a FILE called index.js and observe that it erroneously has a folder icon.
  • clear the file-icons icon cache
  • restart atom and observe that the index.js file correctly has a javascript file icon.

Custom Styles

I have very few custom styles associated with my IDE, but I will add them here:

.name.icon,
.tab > .icon {
  &[data-name*="docker"]:before,
  &[data-name=".yarn-error.log"]:before,
  &[data-name=".yarnrc"]:before {
    color: @medium-blue;
  }
  &[data-name*=".jsonlint"]:before,
  &[data-name*="npm-debug"]:before,
  &[data-name=".nsprc"]:before {
    .fi;

    content: "\e91c";
    color: @medium-red;
    font-size: 17px;
  }
  &[data-name=".yarn-error.log"]:before,
  &[data-name=".yarnrc"]:before {
    .fi;

    content: "\ea1a";
    font-size: 16px;
  }
  &[data-name=".DS_Store"]:before {
    color: white;
    content: "💩";
    top: 1px;
  }
  &[data-name*="docker"]:before {
    .fi;

    content: "\f106";
    font-size: 18px;
  }
  &[data-name=".nycrc"]:before {
    .fi;

    content: "\e974";
    color: @light-green;
  }
}

.tab > .icon {
  &[data-name*=".jsonlint"]:before,
  &[data-name*="npm-debug"]:before,
  &[data-name=".nsprc"]:before,
  &[data-name*="docker"]:before {
    top: 3px;
  }
  &[data-name=".nycrc"]:before,
  &[data-name=".yarn-error.log"]:before,
  &[data-name=".yarnrc"]:before {
    top: 2px;
  }
  &[data-name=".DS_Store"]:before {
    top: 1px;
  }
}

.status-ignored {
  .name.icon:before {
    color: rgba(155, 159, 181, 0.6);
  }
}

Great plugin! Appreciate the work you're doing here. I think it's a necessary plugin. Let me know if there's anything I can do to help debug this issue further.

@Alhadis
Copy link
Member

Alhadis commented Jan 4, 2017

Thanks for the kind words. ;)

I'm afraid this is tied down to atom/tree-view#966. Atom's tree-view doesn't dispatch any event to let other packages know when an entry has been deleted, so there's nothing to notify us when a cache has to be refreshed...

@jeyj0
Copy link

jeyj0 commented Jan 26, 2017

Just mentioning that the same issue occurs when renaming a parent folder - all contained files are without icons.

Keep up the great work :)

@Alhadis
Copy link
Member

Alhadis commented Feb 3, 2017

@jeyj0 Can you give me the steps to reproduce? Renaming a folder closes it in tree-view, and its contents have correct icons once it's opened.

@Alhadis Alhadis self-assigned this Feb 3, 2017
@Alhadis Alhadis added blocked Unable to address issue until actions are taken elsewhere (e.g., merging a pull-request). bug Confirmed defect in package logic, deprecation notices, and PRs which fix them. labels Feb 6, 2017
@Alhadis
Copy link
Member

Alhadis commented Feb 6, 2017

Okay, I've tried everything. There's really no way to fix this without introducing new problems.

Those interested in tracking the state of this issue are advised to follow atom/tree-view#966.

Until that's merged, there's nothing (safe) we can do. 😞

@Alhadis Alhadis added atom-fs Filesystem-related issues to address when developing a stable release of the `atom-fs` module. and removed blocked Unable to address issue until actions are taken elsewhere (e.g., merging a pull-request). labels Oct 22, 2017
@MatthieuLemoine
Copy link

@Alhadis As atom/tree-view#1049 was merged, are there any remaining obstacles to fix this issue ?

@Alhadis
Copy link
Member

Alhadis commented Dec 27, 2017

@MatthieuLemoine I'm currently without a laptop with a graphical display, which means I'm unable to do anything Atom-related for a while. :(

I don't know how long I'm going to be like this, because I don't exactly have the money to afford a new MacBook.

@MatthieuLemoine
Copy link

@Alhadis I'm willing to make a PR. As you tried to fix it, can you give me some leads on how it could be fixed ?

@Alhadis
Copy link
Member

Alhadis commented Dec 27, 2017

It largely ties down to the atom-fs module, which isn't being notified of changes to the filesystem (at least, those which aren't being tracked by the package). Now that Atom has a formal API for filesystem watching, it should be much easier to achieve than what I originally planned.

@Lassi
Copy link
Contributor

Lassi commented Jan 6, 2018

Hey there,

I submitted a PR to fix this issue but I'm not familiar at all with the Atom ecosystem. Please let me know what you think about it!

Cool plugin by the way, thanks for all the work you've done ;)

Alhadis pushed a commit that referenced this issue Jan 8, 2018
The `FileSystem` module wasn't being notified on resource deletion which
resulted in an inconsistent state of the resource cache. By subscribing
to deletion notifications for files in the project and destroying the
resource if it's cached in the `FileSystem` module, we solve that issue.

Fixes #490
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
atom-fs Filesystem-related issues to address when developing a stable release of the `atom-fs` module. bug Confirmed defect in package logic, deprecation notices, and PRs which fix them.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants