Not synced: “file to open is a directory”

Expected behavior

I have set up a few folders to sync with my desktop client. It was working fine until recently.

Actual behavior

One subfolder (named latex) is not synchronized and it shows the issue file to open is a directory. The error is persistent after restarting.

Steps to reproduce

I did recently make some changes to that folder, which are also reflected in the log below. There was a folder named latex which I renamed to latex-obsolete. Then I created a new folder named latex in the same directory and moved latex-obsolete inside latex.

All these changed were made on another device and synced successfully to the server (verified using the web interface of the server).

Server configuration

I don’t know the configuration, the server is https://uni-bonn.sciebo.de.

Client configuration

  • Client version: 2.7.6 (build 3261)
  • Operating system: Ubuntu 20.04.2
  • OS language: en_US.UTF-8
  • Qt version used by client package: 5.12.10
  • Client package: https://download.owncloud.com/desktop/ownCloud/stable/latest/linux/Ubuntu_20.04
  • Installation path of client: /usr/bin/owncloud

Logs

This is what I’d consider to be the relevant part of the logfile. Please request more specific info if needed.

Note that I have censored folder names. The root folder configured for sync is _0_, some subfolder of it is _1_.

04-06 12:13:24:475 [ info gui.application ]:	Sync state changed for folder  "_0_" :  "Sync Running"
04-06 12:13:24:479 [ info sync.propagator ]:	Starting CSyncEnums::CSYNC_INSTRUCTION_RENAME propagation of "_1_/latex/latex-obsolete" by OCC::PropagateLocalRename(0x55a499773660)
04-06 12:13:24:479 [ debug sync.propagator.localrename ]	[ OCC::PropagateLocalRename::start ]:	MOVE  "_1_/latex"  =>  "_1_/latex/latex-obsolete"
04-06 12:13:24:479 [ warning sync.filesystem ]:	Error renaming file "_1_/latex" to "_1_/latex/latex-obsolete" failed:  "file to open is a directory"
04-06 12:13:24:479 [ debug sync.database.sql ]	[ OCC::SqlQuery::bindValue ]:	SQL bind 1 "_1_/latex"
04-06 12:13:24:479 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "SELECT lastTryEtag, lastTryModtime, retrycount, errorstring, lastTryTime, ignoreDuration, renameTarget, errorCategory, requestId FROM blacklist WHERE path=?1"
04-06 12:13:24:479 [ warning sync.propagator ]:	Could not complete propagation of "_1_/latex/latex-obsolete" by OCC::PropagateLocalRename(0x55a499773660) with status OCC::SyncFileItem::NormalError and error: "file to open is a directory"
04-06 12:13:24:480 [ debug sync.statustracker ]	[ OCC::SyncFileStatusTracker::slotItemCompleted ]:	Item completed "_1_/latex/latex-obsolete" OCC::SyncFileItem::NormalError CSyncEnums::CSYNC_INSTRUCTION_RENAME
04-06 12:13:24:480 [ debug sync.database.sql ]	[ OCC::SqlQuery::bindValue ]:	SQL bind 1 -8652598514219694343
04-06 12:13:24:480 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
04-06 12:13:24:480 [ debug sync.database.sql ]	[ OCC::SqlQuery::bindValue ]:	SQL bind 1 -7003911031784969751
04-06 12:13:24:480 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
04-06 12:13:24:480 [ debug sync.localdiscoverytracker ]	[ OCC::LocalDiscoveryTracker::slotItemCompleted ]:	inserted error item "_1_/latex"

Hi @Lilalas,

I think the fastest way if you contact your sciebo support people, they can run some commands in the server to verify your information.

Carlos

Thank you! To clarify, I don’t need help. I already got complete access to my data via the web interface.

However, I think this issue might be caused by an obscure bug in the desktop client. I was very surprised I couldn’t find any meaningful discussion about this particular error message on the web, that’s why I made this public post. Cheers!

Thank you for posting the issues.

The fastest way for you will be to write to info(at)sciebo.de and they let us know immediately. additionally, they have a lot of experience and always glad to help.

Great that the problem is solved now :wink: