Skip to content

Conversation

althonos
Copy link
Member

@althonos althonos commented Sep 26, 2020

Type of changes

  • Bug fix

Checklist

  • I've run the latest black with default args on new code.
  • I've updated CHANGELOG.md and CONTRIBUTORS.md where appropriate.
  • I've added tests for new code.
  • I accept that @willmcgugan may be pedantic in the code review.

Description

Closes #425

Changes the expected behaviour of FS.islink in tests so that is never raises ResourceNotFound, to be consistent with FS.isfile and FS.isdir.

Changes the base FS.islink implementation to one that uses FS.gettype to check if the resource type is symlink.

Closes #411

Fixes the behaviour of the following OSFS methods so that they work as expected:

  • OSFS.islink(path): returns True on existing path to a symlink, False otherwise
  • OSFS.gettype(path): returns ResourceType.symlink is the path maps to a symlink (not the case before)
  • OSFS.getinfo(path): works even if path is a dangling symlink (TODO)
  • OSFS.scandir(dir): works even if dir contains a dangling symlink (TODO)

@althonos althonos self-assigned this Sep 26, 2020
@althonos
Copy link
Member Author

ping @mjpieters, @dargueta

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

Successfully merging this pull request may close these issues.

Default implementation of FS.islink is probably wrong OSFS Bug: incorrect handling of symbolic links with non-existing target
1 participant