file not deleted via webDAV

file not deleted via webDAV - Streams dev

Einer von Vielen

Mon, 14 Nov 2022 12:47:24 +0100 via streams

@mike (mike@unfediverse.com)

Preconditions: two clones A and B. A computer is connected via webDAV to clone A.

Steps:

upload a photo (via web browser or webDAV)
delete the photo via webDAV on server of clone A

Result

server of Clone A: success
server of Clone B: no effect, the photo is not deleted

The deletion works as expected if the the photo is deleted using a web browser.

mike

Mon, 14 Nov 2022 20:24:52 +0100 via y

Followed those instructions precisely, and the photo was removed from the clone. I hope this didn't involve a Windows machine because I don't have any convenient way to test that. But there are three different paths a removed file can take and I've tested two of them and reviewed the code for the third since I can't actually trigger it in my test environment.

If you wish me to continue with this one I'll need to see the sync data from your logs on clone B. This will require setting your log level to LOGGER_DATA for at least the time it takes to get a snapshot.

Look for a line containing the string 'Channel sync received: Array' and I'll need everything from there to the end of that log entry. If you don't see this line (with log level set to maximum), the sync packet is probably still queued on clone A and would indicate there's a delivery issue involved.

On Clone A when set to log level LOGGER_DATA you should see a line with "build_sync_packet" followed by the packet we're sending. This should match the one received on Clone B, assuming it was received.

Einer von Vielen

Thu, 17 Nov 2022 19:14:59 +0100 via streams

Shortly after 17:59:00 I deleted the photo 2022-11-13_14-12-25_Frühstück bei Oda - Susi und Uwe.jpg on digitalesparadies.de in the file explorer of Debian11, Gnome "Files". The directory was mounted via webDAV.

Below the logfiles involved of both server.

What I do not understand is why there is the ".Trash-1000" directory involved.

I retest and take care that I do not delete the file in the Trash.

Einer von Vielen

Thu, 17 Nov 2022 19:27:58 +0100 via streams

...but the trash file that was created by the delete process seems to cause an sql error

2022-11-17T17:59:02Z:LOG_ERR:91c306a3cc:dba_driver.php:506:db_logger: dba_pdo: ERROR: update attach set display_path = '.Trash-1000/info/2022-11-13_14-12-25_Fr..hst..ck bei Oda - Susi und Uwe.jpg.trashinfo where hash = 'c3bb2d04-a75b-4882-b1b8-566b466cb680' and uid = 8
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'c3bb2d04-a75b-4882-b1b8-566b466cb680' and uid = 8' at line 1

Einer von Vielen

Thu, 17 Nov 2022 19:40:57 +0100 via streams

If I use the "rm" command in the terminal the file is successfully deleted on the clone. In this case there is also nothing created in the ".Trash-1000" directories.

Einer von Vielen

Thu, 17 Nov 2022 19:46:57 +0100 via streams

What I do not understand is why there is the ".Trash-1000" directory involved.

I was not clear in expressing this... Yes, of course this is clear, because the Trash is involved if I delete the file in the file explorer of Gnome. And that causes the sync via webDAV and that causes the data base error.

Einer von Vielen

Thu, 17 Nov 2022 19:48:33 +0100 via streams

OMG... my English is sometimes more German using English words.

But you know what is going on now I hope.

mike

Thu, 17 Nov 2022 19:56:25 +0100 zuletzt bearbeitet: Thu, 17 Nov 2022 20:08:19 +0100 via y

I understand the problem now. It isn't with sync and 'delete', but with sync and 'rename'. That's what happens when there's a trash folder involved and I can confirm there's a bug in that workflow. I'll get it sorted.

Edit: And the bug involves a bit more work than just fixing the SQL.

Einer von Vielen

Thu, 17 Nov 2022 22:50:44 +0100 via streams

Independent from this... I will use either rm in the terminal or "delete permanently" in the file explorer instead of just "delete" (move to trash).

And the bug involves a bit more work than just fixing the SQL.

This will probably give an interesting "read" of the git in the next couple of days for me. (Good night!)

mike

Sat, 19 Nov 2022 19:40:10 +0100 via y

Should be #fixed.

Einer von Vielen

Sun, 20 Nov 2022 16:09:54 +0100 via streams

Should be #fixed.

confirmed, works