Skip to content

fix: wrong permissions directory#6172

Merged
nathanlesage merged 4 commits into
Zettlr:developfrom
krisfremen:kris/fix-permissions
Mar 8, 2026
Merged

fix: wrong permissions directory#6172
nathanlesage merged 4 commits into
Zettlr:developfrom
krisfremen:kris/fix-permissions

Conversation

@krisfremen

Copy link
Copy Markdown
Contributor

Description

Fixes an issue with zettlr crashing upon startup because of an unhandled exception when accessing a directory that current use doesn't have permissions towards.

Changes

List directories that aren't accessible as dirNotFoundFlag-ed

Additional information

Fixes #6162

Tested on: openSUSE Tumbleweed, PopOS

@boring-cyborg

boring-cyborg Bot commented Feb 11, 2026

Copy link
Copy Markdown

Thank you for opening your first PR! 🎉 We would like to thank you already for your contribution. If everything checks out, we'll make sure to review the PR as soon as possible and give feedback. Please note a few things:

  • For every PR, the automated pipeline will run the linter and unit tests on
    your code. Should these fail, we will not merge your PR.
  • Activate your notifications and check your inbox regularly to respond to our
    reviews and/or comments.

We are glad for every improvement that makes its way into the app, so we look forward to collaborating on merging this PR.

@nathanlesage

Copy link
Copy Markdown
Member

This looks fine in principle! There's just a merge conflict now because I merged the dot-file PR just now. But that should make the PR a bit cleaner I guess, since it only involves a few try/catch instances, no?

Aside of that, I'm curious — does this finally re-enable the "DirNotFound" descriptor functionality in the file tree? I implemented that years ago due to a request by someone who had their workspaces on a USB key and who sometimes forgot to plug it in before starting Zettlr. At some point, that got lost (and I never really understood why)…

@krisfremen

Copy link
Copy Markdown
Contributor Author

This looks fine in principle! There's just a merge conflict now because I merged the dot-file PR just now. But that should make the PR a bit cleaner I guess, since it only involves a few try/catch instances, no?

Aside of that, I'm curious — does this finally re-enable the "DirNotFound" descriptor functionality in the file tree? I implemented that years ago due to a request by someone who had their workspaces on a USB key and who sometimes forgot to plug it in before starting Zettlr. At some point, that got lost (and I never really understood why)…

Resolved the merge conflict.

Indeed, it does bring back the DirNotFound descriptor.
Upon further testing though, it seems like the "Check for directory" rescan isn't implemented.
I haven't tried out the workspace on a USB key, but I can test that out too.

@nathanlesage

Copy link
Copy Markdown
Member

Upon further testing though, it seems like the "Check for directory" rescan isn't implemented.

That sounds like another PR at a different time. It looks good, though! Merging…

@nathanlesage nathanlesage merged commit abc80a7 into Zettlr:develop Mar 8, 2026
1 check passed
return await this.getAnyDirectoryDescriptor(absPath)
} catch (err: any) {
if (err.code === 'EACCES' || err.code === 'EPERM') {
return FSALDir.getDirNotFoundDescriptor(absPath)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this not be moved to the getAnyDirectoryDescriptor? I think it would be more robust to put the check and fallback within that function

const ignoreDotFiles = !files.dotFiles.showInFilemanager && !files.dotFiles.showInSidebar

try {
const contents = (await fs.readdir(directoryPath, { withFileTypes: true, recursive: true }))

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason you reverted this change, removing { recursive: true }?

)
return [ directoryPath, ...contents.flat() ]
} catch (err: unknown) {
const code = err instanceof Error ? (err as NodeJS.ErrnoException).code : undefined

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is redundant with the below logging and return statement

Comment on lines 872 to +882
try {
const children = await fs.readdir(absPath, { withFileTypes: true })
return await Promise.all(
children
.filter(dirent => {
return (!ignorePath(dirent.name, ignoreDotFiles) && (dirent.isFile() || dirent.isDirectory()))
})
.map(dirent => {
const childPath = path.join(absPath, dirent.name)
return this.getDescriptorFor(childPath)
})
)
children = await fs.readdir(absPath, { withFileTypes: true })

const childPaths = children
.filter(dirent => !ignorePath(dirent.name, ignoreDotFiles) && (dirent.isFile() || dirent.isDirectory()))
.map(dirent => path.join(absPath, dirent.name))

const results = await Promise.allSettled(childPaths.map(p => this.getDescriptorFor(p)))
return results
.filter((r): r is PromiseFulfilledResult<AnyDescriptor> => r.status === 'fulfilled')
.map(r => r.value)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the motivation for this refactor? To me it just seems to make things more verbose without any extra guard or tests

@benniekiss

Copy link
Copy Markdown
Collaborator

Sigh, I never actually submitted my comments after writing them. Well, there they are now

@benniekiss

benniekiss commented Mar 8, 2026

Copy link
Copy Markdown
Collaborator

My only real concern is the reversion of the readdir({ recursive: true }) option. Since that removes the function call recursion, I believe it avoids any stack-call-depth errors a la #6116

Otherwise, the other changes are fine to me

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.

Zettlr won't start if workspace contains directory that's not accessible by user running Zettlr

3 participants