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

.DS_Store open by default? #96

Open
dragonxlwang opened this issue Mar 8, 2016 · 9 comments
Open

.DS_Store open by default? #96

dragonxlwang opened this issue Mar 8, 2016 · 9 comments

Comments

@dragonxlwang
Copy link

Recently after upgrading to 0.14.3 I found that advanced-open-file will always open ".DS_Store" file of the directory by default (I am using a Mac). How can I disable it? This won't happen when using default open file in atom though. Thanks,

image

@Osmose
Copy link
Owner

Osmose commented Mar 8, 2016

Thanks for the report!

When is it opening the file? While you're browsing, it just opens automatically? Or is it when you try to open another file?

Basically, what are your steps to reproduce?

@dragonxlwang
Copy link
Author

yes. For example:

  1. open adv-open-file by alt+cmd+o
  2. type "~/workspace/foo.bar"
  3. it will open both ~/workspace/foo.bar and ~/workspace/.DS_Store. The later one opened automatically.

My current temp fix is to delete all .DS_Store in workspace recursively...

@Osmose
Copy link
Owner

Osmose commented Mar 8, 2016

That's really weird; I'm unable to replicate this. I'm also on OSX.

It might be a weird interaction with another package. Does this problem persist if you disable all your other installed packages temporarily?

@dragonxlwang
Copy link
Author

yes. I am having this problem with only the advanced-open-file packages… Not sure if this is related to OS X instead…?

On Mar 8, 2016, at 2:11 PM, Michael Kelly notifications@github.com wrote:

That's really weird; I'm unable to replicate this. I'm also on OSX.

It might be a weird interaction with another package. Does this problem persist if you disable all your other installed packages temporarily?

@dragonxlwang
Copy link
Author

I realized maybe this is due to that I set defaults write com.apple.finder AppleShowAllFiles YES a while ago. However, not sure if that is indeed the cause.

@Osmose
Copy link
Owner

Osmose commented Apr 17, 2016

I'm still unable to replicate this. My system setting for com.apple.finder AppleShowAllFiles is 1, which I believe is equivalent to your value. At least, my Finder shows hidden files fine.

If you create a directory with two files in it, .DS_Store and foo.bar, and try to open foo.bar, does it still auto-open .DS_Store as well? If not, what if you delete .DS_Store, create an image file within the directory, and then view it in Finder to generate a real .DS_Store file?

Basically I'm try to get an isolated test case that I can play around with replicating. Any help you can give is appreciated! :D

@ripter
Copy link

ripter commented May 6, 2016

I was unable to replicate the issue. I recored my attempt: https://youtu.be/zi8PPT0H5Hc
@dragonxlwang is there something I'm doing differently?

@pirminis
Copy link

pirminis commented Jul 3, 2016

this issue is present for me too.

further are instructions.

requirements:

  • atom-beta@1.9.0-beta0
  • advanced-open-file@0.16.3
  • example root path for project: /a/b/c

Options:

  • Create directories
  • Create files instantly
  • Default input value – Project root
  • Use fuzzy matching for matching filenames
  • Shortcuts for fast directory switching

Then:

  • open advanced open file dialog using command pallete (cmd-shift-p)
  • IMPORTANT: if root path is /a/b/c, and directory /a/b/c/d/e exists, then new file should be /a/b/c/d/e/newfile.here. Creating new file in root path doesn't reproduce this bug
  • press enter, new file is created. .DS_Store file is opened automatically too.

Noted:

  • automatically opened .DS_Store file resides in root path, aka /a/b/c/.DS_Store

@Osmose
Copy link
Owner

Osmose commented Jul 15, 2016

@pirminis I followed your steps to the letter, same atom version, same package version, same settings, etc. and am still unable to replicate the issue. Could you find a directory tree where you consistently experience the issue and then share the filenames in that tree? The out of the tree command would be ideal.

I'm wondering if it has something to do with the directory layout that's confusing the fuzzy finding code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants