Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Nextcloud Desktop 34.0.4 fails TestLocalDiscovery::testFileOpenedAsDirectoryCompletesDiscoveryJob()

Open Beginner friendly
  • Is something wrong?
#10,930 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
desktop, testing-qa

Research direction

Start with src/libsync/discoveryphase.cpp around DiscoverySingleLocalDirectoryJob::run(), then run test/testlocaldiscovery.cpp, especially testFileOpenedAsDirectoryCompletesDiscoveryJob(). Verify that opening a regular file follows the ENOTDIR path and emits finished despite logging or timezone configuration; the targeted test should pass.

Written by the indexing model from the issue text.

Description

0. Needs triage bug
⚠️ Before submitting, please verify the following: ⚠️
Bug description

FAIL! : TestLocalDiscovery::testFileOpenedAsDirectoryCompletesDiscoveryJob()
Compared values are not the same
Actual (finishedSpy.count()): 0
Expected (1) : 1
Loc: [test/testlocaldiscovery.cpp(49)]

Compilation succeeds. This is the only failing test among the 67 enabled tests, and it fails on all five attempts.

Suspected cause:

In DiscoverySingleLocalDirectoryJob::run(), a failed csync_vio_local_opendir() is followed by logging and translation before errno is checked:

qCInfo(lcDiscovery) << "Error while opening directory" << localPath << errno;
QString errorString = tr("Error while opening directory %1").arg(localPath);
if (errno == EACCES) {
// ...
} else if (errno == ENOENT) {
// ...
} else if (errno == ENOTDIR) {
Q_EMIT finished(QVector{});
return;
}

Those intervening operations can overwrite errno. A standalone reproducer using the same Qt version and Nextcloud’s timestamp formatting, with TZ pointing to a nonexistent file, produces:

Before logging: 20 (ENOTDIR)
After logging: 2 (ENOENT)
After translation: 2 (ENOENT)

This would send discovery down the wrong error branch instead of emitting finished. Missing timezone data in the build environment is the suspected trigger; the exact overwrite within the full test has not yet been instrumented.

This patch fixed it for me:

Preserve the directory-open error across logging and translation.

Timestamp formatting can overwrite errno when timezone files are unavailable,
causing ENOTDIR to be treated as another error and suppressing the finished
signal expected by testFileOpenedAsDirectoryCompletesDiscoveryJob.

--- a/src/libsync/discoveryphase.cpp
+++ b/src/libsync/discoveryphase.cpp
@@ -353,15 +353,17 @@

 auto dh = csync_vio_local_opendir(localPath);
 if (!dh) {

  •    qCInfo(lcDiscovery) << "Error while opening directory" << (localPath) << errno;

  •    // Logging and translation may overwrite errno.

  •    const int openError = errno;

  •    qCInfo(lcDiscovery) << "Error while opening directory" << (localPath) << openError;
   QString errorString = tr("Error while opening directory %1").arg(localPath);

  •    if (errno == EACCES) {

  •    if (openError == EACCES) {
       errorString = tr("Directory not accessible on client, permission denied");
       Q_EMIT finishedNonFatalError(errorString);
       return;

  •    } else if (errno == ENOENT) {

  •    } else if (openError == ENOENT) {
       errorString = tr("Directory not found: %1").arg(localPath);

  •    } else if (errno == ENOTDIR) {

  •    } else if (openError == ENOTDIR) {
       // Not a directory..
       // Just consider it is empty
       Q_EMIT finished(QVector<LocalInfo>{});
Steps to reproduce

im updating the package for guix and encountered this.

Expected behavior

Scanning a regular file as a directory should follow the ENOTDIR branch and emit finished, regardless of logging or timezone configuration.](url)

Which files are affected by this bug

.

Operating system

Linux

Which version of the operating system you are running.

.

Installation method

Compiled it myself (please test with the AppImage package ?)

Nextcloud Server version
Nextcloud Desktop Client version

34.0.4

Did this occur after an update or on a clean installation?

Minor version update (i.e. 33.0.0 → 33.0.1)

Are you using the Nextcloud Server Encryption module?

Yes

Are you using an external user-backend?
  • Default internal user-backend
  • LDAP or Active Directory
  • SSO - SAML
  • Other
Nextcloud Server logs
Additional info

No response

Dominant language
C++
Stars
3.9k
Forks
1k
Avg merge
1d 3h
Merged PRs (30d)
137

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nextcloud/desktop

All issues in nextcloud/desktop

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.