Skip to content

[Discussion] Should ^ create sub-directories when wrapWithDirectory is true? #177

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

Closed
rafaelramalho19 opened this issue Oct 25, 2021 · 2 comments · Fixed by #192
Closed
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up released

Comments

@rafaelramalho19
Copy link

As discussed in web3-storage/web3.storage#375, filenames with ^ are creating sub-directories for each ^ present.
Do you believe this is something that we should address here or should this package continue with that functionality?

@rafaelramalho19 rafaelramalho19 added the need/triage Needs initial labeling and prioritization label Oct 25, 2021
@lidel lidel added kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up P2 Medium: Good to have, but can wait until someone steps up help wanted Seeking public contribution on this issue need/analysis Needs further analysis before proceeding and removed P2 Medium: Good to have, but can wait until someone steps up need/triage Needs initial labeling and prioritization labels Nov 19, 2021
@yusefnapora
Copy link
Contributor

yusefnapora commented Jan 31, 2022

It doesn't look like this behavior is intentional...

AFAICT, it's happening due to this regex:

const toPathComponents = (path = '') => {
  // split on / unless escaped with \
  return (path
    .trim()
    .match(/([^\\^/]|\\\/)+/g) || [])
    .filter(Boolean)
}

The comment suggests it's supposed to split on / characters, but the regex is also matching ^ as a literal char, not a regex control character.

@github-actions
Copy link

🎉 This issue has been resolved in version ipfs-unixfs-importer-v9.0.7 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up released
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants