Bug 31702

after cleaning my local cache
rm -f /home/marc/.davfs2/cache/dest/*
it works again.

Looks like if run into this bug:
https://savannah.nongnu.org/bugs/?63771

Please confirm the package & version; as in the SRPM field?

(In reply to Marc Krämer from comment #1)
> Looks like if run into this bug:
> https://savannah.nongnu.org/bugs/?63771
This refers specifically to  "nginx dav module and special chars". Did you have either of these?
"I tried using this simple script as webdav server: https://gist.github.com/mickael-kerjean/f2f034bdad5e077edcbfdff649d52d68
And the above steps won't make any crashes, the file content can be normally shown."
No other action on the bug.

https://savannah.nongnu.org/bugs/?63364
"davfs2 1.7.0 mounts segfault when accessed with dolphin"
Is this your case? No action on the bug.

(In reply to Marc Krämer from comment #0)
> this is pretty essential for my daily work - and I'm pretty sure this has
> worked last week.
I can see no Cauldron activity on this since:
Nov 19 2022 : update to 1.7.0
So can you look for something else that has changed recently? Can you relate it to a kernel update?

Source RPM: (none) => davfs2-1.7.0-1.mga9.src.rpm
CC: (none) => lewyssmith

I should have lowered the priority after I found the reason.

It looks like davfs has some bugs handling special files. In my case these files were not on the server, but on the client in the lost+found directory. Not sure if netbeans really tried to access them and caused the crash. But I was unable to remove them while davfs is mounted - I had to remove them from the cache folder when davfs is unmounted. Afterwards it works like ever.

Severity: major => minor

Thanks for the detective work and good result. Can you say for others what you mean by 'special files'? How did you identify them?

Can we - you - close the bug?

Noted for M9 Errata.

Keywords: (none) => FOR_ERRATA9

In lost+found a file is saved, when the remote host does not accept the file (e.g. down, or write protected, ...) so lost+found fills over the time.
The files saved here are named: originalfile.txt-HASH so besides the "-" there is nothing special about it. An example is:
manage.tmpl-2m83k5
manage.tmpl-3uA4Kk

But it looks like the dir-index of "lost+found" causes this problem and I guess it is the "+" sign:

cd lost+found/
[marc@localhost lost+found]$ ls
ls: cannot access 'dir-lost+found-xhbokx': Software caused connection abort
ls: cannot access 'dir-lost+found-rLn3pO': Transport endpoint is not connected
....

Status: NEW => UPSTREAM

Can we assign this to pkg-bugs? Nothing that Bugsquad can do with it.

Sure, we need an upstream update to get this fixed. But it is the bugreport we need, to get an updated version into stable mga9 :)

happend again - files in lost+found of davfs seems to cause this error, or a broken lookup file which determines which cached file belongs in lost+found and which is a regular file

Added a fix, restores speed and does not crash anymore.

Update in core/updates_testing
davfs2-1.7.0-2.mga9

SRPM:
davfs2-1.7.0-2.mga9.src.rpm

Assignee: pkg-bugs => qa-bugs

Great work, Marc.
Since you are the only complainant so far, if this works for you - can we call it MGA9-64-OK ? I doubt whether QA will be able to test the fault in question, nor indeed the application; only that the update happens OK.

Sure, we can.

This is still cauldron in version freeze, not release freeze.

Request a freeze push in the dev ml.

CC: (none) => davidwhodgins

moved

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED