GNOME Bugzilla – Bug 509602
Add burn: write support
Last modified: 2018-09-21 16:16:12 UTC
We need to add a burn: backend that nautilus-cd-burner can use. Long term this should perhaps be shipped in the nautilus-cd-burner module, but for now we want to keep all backends inside gvfs so we can keep tweaking the APIs.
Initial work is in, but write support and monitoring is still lacking
*** Bug 553013 has been marked as a duplicate of this bug. ***
Would this backend allow access via gvfs fuse, or should I file a separate bug about that?
The fuse filesystem does nothing but proxy to the backends. However, some backends are intentionally not visible as fuse filesystems (think of network: trash: computer: etc). I think at the moment burn: is one of those. This could be changed if that seems to be the right thing to do.
I think it probably should be made visible since it is visible to other gio using apps. Meaning when you double click on an item in burn:// it does normally open if the app using gio. For apps that just get access via gvfs fuse it does not work however since it doesn't map to a fuse fs.
computer:/// is visible to other gio using apps too. That doesn't seem to be a good argument. Its more a question about cluttering the filesystem vs the chances that normal users would want to open a file somewhere in a non-gio app. For the case of burn:// what is the usecase where you would want to access these files with a non-gio app? The typical usecase is that you drag stuff to burn with nautilus, maybe fuss around a bit with the directory layout, then burn and forget.
But at least as I understand it you can't have files directly inside of computer:/// that you can double click on and have nautilus attempt to have open in an application. This happens with burn:// currently. Since it does happen when you do double click on an OOo document it starts OOo but then can't load the file since it isn't exported via fuse. This also didn't work properly when Ubuntu's OOo was using gnome-vfs perhaps for similar reasons. A user filed a bug about this very instance (gnome-vfs) on Ubuntu some time ago. https://bugs.launchpad.net/bugs/120069
If a mount isn't visible in the fuse mount then we will pass in the URI instead.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/29.