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

Unable to check file attributes for hidden flag on Windows OS #379

Closed
nelsonni opened this issue Mar 16, 2021 · 1 comment
Closed

Unable to check file attributes for hidden flag on Windows OS #379

nelsonni opened this issue Mar 16, 2021 · 1 comment
Assignees
Labels
bug Bug reports or bug fixes dependencies Issues or updates to dependency files

Comments

@nelsonni
Copy link
Member

Describe the bug
In order to resolve #113 on Windows OS, the io.isHidden function has been added to abstract away the details for determining if a filepath points to a hidden file:

export const isHidden = (filepath: fs.PathLike): boolean => {
const isWindows = process.platform === 'win32';
if (isWindows) {
return extractFilename(filepath).startsWith('.');
} else {
return shouldBeHiddenSync(filepath.toString());
}
}

This function is meant to be a temporary shim to circumvent the fact that the hidefile package currently fails when attempting to read file attributes on Windows OS platforms (see stevenvachon/hidefile#3). There are currently no alternative packages that are known to properly read file attributes on Windows OS, so until the hidefile package is patched this issue will remain open.

Versions (please complete the following information):

  • OS: Windows
  • Synectic Version: 1.0.0-beta (branch: development)

Additional context
The io.isHidden function was added in #359, and additional discussion details can be found within that PR.

@nelsonni nelsonni added bug Bug reports or bug fixes dependencies Issues or updates to dependency files labels Mar 16, 2021
@nelsonni
Copy link
Member Author

This issue is no longer relevant and has been superseded by switching to using find-up::findUp instead of isomorphic-git::findRoot in getRoot in v3.0.0. Per the discussions in #359, the issue was primarily occurring when the getRepoRoot function (now called getRoot) would read an empty directory on Windows. This appeared to have been occurring when getStatus was called, which is now also transitioned to using git directly instead of isomorphic-git.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug reports or bug fixes dependencies Issues or updates to dependency files
Projects
None yet
Development

No branches or pull requests

2 participants