I tried to mount a nextcloud15 folder with Thunar. It logs in correctly and displays the folder contents. But it has (small) problems reading files from the webdav share and (severe) problems writing to them. Write does not work in most cases (probably 1 out of 50 works), read is better but still has problems every now and then. I tried a different way of access through gigolo, which has quite the same problems. On the command line (mount.davfs ....) everything works flawlessly as expected. System is latest arch linux.
PS: Even if writing by copy works, loading an odt file in libreoffice and re-writing it does not. If you need a test that fails for sure try libreoffice saving a doc.
Thunor only offers webdav support via gvfs[1]. Since you reported that the bug as well exists within gigolo, I assume it is a gvfs bug. Best take another try for nautilus, which as well uses gvfs, in order to see if it shows the same bug .. and if so, you can report it on https://gitlab.gnome.org/GNOME/gvfs [1] https://wiki.gnome.org/Projects/gvfs
I already thought of that, tested PCManFM, and it shows the same problem.
I just found out that this is an old and still open issue of gvfs and nobody really cares about it. The issue is dead for 4 months now ...
Maybe worth to try "gvfs-mount" on console to see if some error is shown (package gvfs-bin) At least you can add "hey, I have the same issue" to possibly raise attention on the bug. If you can, maybe it is worth to try older gvfs version to see which version made the difference (or best to use git bisect to find the corresponding commit) Good luck on finding a solution for it !
After reading and googling a bit around I have to tell you that the basic problem of all mentioned filemanagers is indeed that their authors have not understood the deficiencies of GVFS. Indeed GVFS _cannot_ handle files correctly and is a pretty bad choice for including a remote-mounted fs into the fs tree. Please note this: ======================================================================== Ondrej Holy 2018-05-14 12:01:59 UTC Created attachment 372004 [details] [review] fuse: Add fallback for unsupported write operations Currently, open() fails with ENOTSUP if O_WRONLY/O_RDWR is used without O_TRUNC, or O_APPEND, because GFileIOStream is not supported by GVfs and GIO API doesn't provide any other suitable function. Let's introduce fallback solution using a temporary file as follows: 1) Make a temporary copy of the original file with .fuse suffix (so the new file can be used as a backup if something goes wrong). 2) Replace original file using g_file_replace (i.e. using O_TRUNC) and copy back the data from the temporary file over the GFileOutputStream. 3) Finally, remove the temporary file and return the stream which was used to copy the data back. This approach copies the file twice, once into the temporary location and once back instead of just simple write, which is extremely inefficient (and fragile), but there are not many possibilities using the current API. It would be possible to make just one copy in theory, but I choose this solution to make it more bulletproof. Given the fact that is extremely inefficient, let's limit this only to small files (i.e. return ENOTSUP for big files). I initialy choose the limit to 128 MB, but it can be changed in the future if needed. ========================================================== The above basically means you cannot access files from any software (like libreoffice, abiword or the like) through classical double-clicking and mostly even not through simple open-file-requesters. IT IS USELESS. So I suggest to drop GVFS from file managers completely and use davfs2 mounts for webdav instead. It is pretty clear that the future of centralised file serving uses clouds. And at this time they are all (and only) accessible via webdav. And this works flawlessly in davfs2, and completely buggy in gvfs. So choose your option ...
> So I suggest to drop GVFS from file managers completely So we drop it, because it is not perfect .. which perfect package you want to use instead, which provides the same services for all possible remote location types? > and use davfs2 mounts for webdav instead. How about you provide a patch for gvfs-backends instead, so that it properly uses davfs2 with some extended API? IMO would be a huge waste of time and energy if every file manager implements its own remote protocol API for all possible remote location types. > It is pretty clear that the future of centralised file serving uses clouds. And at this time they are all (and only) accessible via webdav. And this works flawlessly in davfs2, and completely buggy in gvfs. So choose your option ... Well, even if MOST remote files, like in your bright future vision can be accessed via webdav, I belive there still will be SOME files, which will require other remote location types. > The above basically means you cannot access files from any software (like libreoffice, abiword or the like) through classical double-clicking and mostly even not through simple open-file-requesters. IT IS USELESS. You tried the package "libreoffice-gnome" ? I dont have any trouble to open libreoffice stuff on network shares. Here some more info: https://bugs.documentfoundation.org/show_bug.cgi?id=99667
If you read Ondrejs explanations you might have noticed that the problem is _not_ within the application. This is why neither libreoffice nor abiword nor anything else that opens files O_RDWR works as expected. You only think this works at your side because some very bad patches go on in the background (he explains some). The first reference I found to this problem dates back about 10 years ago (afair). Following is an ever ongoing list of people that have all the exact same problem: gvfs not working as a filesystem. There are corresponding issues for webdav, smb and ftp, which means just about every remote file service used. Sure I would like to provide some logs as I have at least two boxes that show the problem constantly and reproducably. So producing logs should be easy. Only the sign-in process at gnome is not easy, at least for my github account it simply does not work. And they seem to have no register-account option. So what do you expect me to do? BTW there is no "libreoffice-gnome" package in arch linux (which I use). And anyway this would not help copy/move and the like in thunar which most of the time doesn't work either.
> Sure I would like to > provide some logs as I have at least two boxes that show the problem > constantly and reproducably. So producing logs should be easy. Only the > sign-in process at gnome is not easy, at least for my github account it > simply does not work. And they seem to have no register-account option. So > what do you expect me to do? I can login there with my gitlab.com account, if that helps. I dont expect you to do stuff .. I only can tell what I would do: Open a bug, tell what is wrong, and wait for reply. If the gvfs API is really that broken, it might be time for a new gvfs API on one of the next gvfs releases ... you might need to digg deep into the gvfs source-code before making that point. > BTW there is no "libreoffice-gnome" package in arch linux (which I use). And > anyway this would not help copy/move and the like in thunar which most of > the time doesn't work either. At least there used to be some "libreoffice-gnome" package for arch in the past. See here: https://bbs.archlinux.org/viewtopic.php?id=172833 I have no idea why it is not packaged any more for arch. In debian it is still available: https://packages.debian.org/de/bullseye/libreoffice-gnome Even though it will not fix any general gvfs problems, it at least enables you to use libreoffice on network shares. Best ask in the arch forum where the package has gone.
It's not me that is indepth talking about the problems of gvfs, its one of the authors. So they already know for years. I do not find it a "solution" to patch some application, as all others will not work. My solution was now to make a mount tool that works (with gtkdialog and davfs2). After that everything works well - except thunar (and some other file managers). They are loosing a lot of time reading in files from webdav only for creating thumbnails. And I have not found a solution for this. Is there any?
> It's not me that is indepth talking about the problems of gvfs, its one of the authors. So they already know for years. Maybe time to remind the authors about that problem :) Who knows if all authors share the same opinion on the issue. As well, if that bug is 10 years old, who knows if some effort to change things already was done meanwhile. For sure will not hurt to ask. > I do not find it a "solution" to patch some application, as all others will not work. Well, it's a solution for that one application :) > They are loosing a lot of time reading in files from webdav only for creating thumbnails. And I have not found a solution for this. Is there any? In thunar you can disable thumbnails on remote locations: edit --> settings --> show thumbnails --> "only for local files" ... gosh I should have told you about that option in the first place .. does it help ?
Unfortunately it does not help. I found all the corresponding options and tried all of them. I read somewhere that the reason is that mounting a cloud by davfs2 and not gvfs thunar is not able to notice that this is in fact no local fs. I don't know if this is true, but the option has indeed no effect at all in this use case. As far as I can see there is no option to disable thumbnails completely, is there?
> Unfortunately it does not help Does it help if you connect via gvfs ? > ... thunar is not able to notice that this is in fact no local fs Yes, think that is the case for all mount points you mounted via "mount" command. > As far as I can see there is no option to disable thumbnails completely, is there? Just set "show thumbnails " to "never".
Sorry to say, but even "show thumbnails never" does not bring the folder listings' time anywhere near doing a simple ls. Using "ls -al" shows the listing instantly. Clicking on the drive in thunar takes 28 seconds to show its content (time taken with stop watch). What is it doing during that time?