SYSTEM PROBLEM: Understanding of "\"

Hi guys,
one day ago I wanted to upload a file in a subfolder of a libary, but I got a “Undefinied Error”. When I want to create a new file in this folder with Seahub, I get “Internal Server Error”. I can sync data into the folder, but the upload function of the client just doesn’t work. I can see all of the libary, share it and download the folder and input. SeaFile log shows this:

[04/01/18 17:16:42] repo-op.c(311): parent_dir /Kirche/CVJM doesn’t exist in repo c1064e4c-3c65-4090-87c0-2531e4b52528.
[04/01/18 17:16:45] repo-op.c(311): parent_dir /Kirche/CVJM doesn’t exist in repo c1064e4c-3c65-4090-87c0-2531e4b52528.
[04/01/18 17:21:25] size-sched.c(96): Repo size compute queue size is 0
[04/01/18 17:26:25] size-sched.c(96): Repo size compute queue size is 0
[04/01/18 17:31:25] size-sched.c(96): Repo size compute queue size is 0
[04/01/18 17:31:33] repo-op.c(311): parent_dir /Kirche/CVJM doesn’t exist in repo c1064e4c-3c65-4090-87c0-2531e4b52528.
[04/01/18 17:31:33] repo-op.c(3448): [put dir] Failed to create empty file dir.
[04/01/18 17:31:34] repo-op.c(311): parent_dir /Kirche/CVJM doesn’t exist in repo c1064e4c-3c65-4090-87c0-2531e4b52528.
[04/01/18 17:31:34] repo-op.c(3448): [put dir] Failed to create empty file dir.
[04/01/18 17:31:44] repo-op.c(311): parent_dir /Kirche/CVJM doesn’t exist in repo c1064e4c-3c65-4090-87c0-2531e4b52528.
[04/01/18 17:31:44] repo-op.c(3448): [put dir] Failed to create empty file dir.
[04/01/18 17:36:25] size-sched.c(96): Repo size compute queue size is 0

I have tried to repair it, but seaf-fsck says everything is Ok, I also tried seaf-gc.

Has anyone an idea? I’m using SeaFile CE 6.2.5 with MariaDB and behind nginx.

Thanks,
bionade

Can you log into the webui and confirm that the folder (CVJM) exists in Seafile?

Yes, and I can download and look on evrything, I also can upload via sync.
I know it’s confusing, but the name of the folder is Kirche\CVJM.

Ok, so, let me try to get some clarification. You say you can sync. But only upload? Also, you stated in your original comment that you can sync but the upload of the client works.

So, I just need some clarification. When I hear “client”, I think of the Seafile client which is installed on a PC in order to sync. So, are you saying that when the client tries to sync a file, that it will sync whatever is already existing in the library on the server? And, that when you drop a file into the sync folder on the client PC that the client never syncs it back to the server?

Or, are you talking about the web interface, that you can’t upload from there?

Also, that seafile log, is it from the server or the client?

Client and webUI can’t upload into the one folder, but the client can sync it. Even upload to the libary is no problem. I think it could be caused by the django interface. And I can download everything out of the folder from everywhere.

Ah, I think I see what you mean now. That is odd. At first, I would assume that you need to run seaf-fsck on it and garbage collection, but I think you said you already did that. Not only does it appear that it can’t find it, it appears that it tries to create it and then subsequently fails.

Any possibility that you can unsync that library, make a backup copy of the files on a client PC, then delete the library in the web UI, then create a new library and try to sync it again?

That may be the quickest solution. It’s really odd that you can see that folder in the web UI, download from it, sync it, but not upload, and it’s only happening on that one repo. It appears that something has gone wrong with that repo.

Yes, of course, renaming and resyncing the libary would be the easiest option, but then you couldn’t find the purpose of this error. If the error wasn’t so weird, I would solve it myself but I want to know why it’s happening.

Looking through the code earlier, my conclusion is that the repo and/or the indexers for it are corrupt. It’s the only conclusion I have without further evidence. The errors are generated from the repo operations file. In this case, it goes and and grabs the repo id and looks for the path in the repo, which it cannot find. So, it thinks it does not exist and tries to create a new folder, which is already existing. Therefore, it generates the errors.

My idea: Linux interpretes a “/” in name as double-backslash in the system (like “Test\ 1” for “Test 1”). But one of seafiles components can’t understand that. So I will search in MariaDB for the right table with the name in it and I will try to reproduce the error by creating the folder Test\Test in the libary Test, and then creating the libary Test\Test and look if the error is appearing.

Some Seafile code does have traps for bad characters in filenames, but I don’t remember seeing those traps in the code earlier… But, that was several hours ago when I last looked at it. But, I didn’t look down that route since I thought it was a path/dir, so it looked normal to me. It would be interesting to know what happens if you name a folder test/test.

Ok, it’s not solved I can create a foder named Test\Test in the libary Test. I made a misstake and write about “/” but I meant “\”. So erverything is again a problem, nothing is solved.
Maybe @daniel.pan could look on it?

Warning: The forum software can’t understand double-backslash, just “” will appear, if you write “double-backslash”.

Same error occurs by creating a file in folder Test\Test in libary Test.
So now I wil try to find why the issue appears.