Real directory name not accessible from file opened via document portal #475
Comments
chergert
changed the title
The
I'm not sure why the application needs to know what the name of the directory the file is in is. |
|
Also, adding a |
Because in a text editor it's helpful to give context to the user as you might have multiple files with the same name in different directories. For example, |
|
Sorry misread that. But it still doesn't fix it for |
|
Additionally, it's nice to open a new |
I've filed this as #477 |
I'm struggling with the same issue for Pika Backup. However, I'm not sure if the portal is supposed to give me the correct path with Can someone update me what's the exact status of this issue? |
Text Editor can show the correct path because while we use GtkFileChooserNative, we don't use the document portal FUSE because the logic in Flatpak knows we can access it by the real path (due to how it scans for symlinks and having set --filesystem=host). However, you can see where this breaks by opening Nautilus and browsing to somewhere like |
|
I didn't get the correct filename because of some strange issue with my build system. Maybe worth adding to the portal docs that the returned path is not always in |
ghost
mentioned this issue
|
My naive first guess would have been that all application simply access files through an overlayfs or similar and that paths (once given the permission) would be accessed at the original URL as it is currently done when using e.g. I would also like to add the problem in which this affects me. For me the problems first showed up once org.telegram.desktop locked down permissions even further by removing |
|
This bug is still present with ro access. |
GeorgesStavracas
added
enhancement
help wanted
portal: documents
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes flatpak#475
This method allows apps to get path as exists on the host filesystem for documents exported through the document portal. This method takes a list of document IDs as a string array and returns a dictionary mapping document IDs to the paths in the host filesystem. It is expected an app making this request to have access to given list of documents. This is based on initial work made by @JakobDev Fixes #475
and others
Currently, when accessing documents via the document portal we're provided with a file in the format of
/run/user/1000/doc/abcdef/filename.txt. This is fine and a nice way to implement things using a FUSE mount to ensure access.However, it's very problematic for applications like text editors. We want to provide information to the user about what file was accessed (including the path). We also want to allow the user to open a file browser or terminal where that file exists. Both of these things are impossible currently unless we grant access to
$HOMEor get lucky with access likexdg-documentsor something like that.I know it's a bit extra work, even for applications, but perhaps we could add a new
G_FILE_ATTRIBUTE_STANDARD_DIRNAMEthat could grab an extended attribute from the FUSE driver.My main argument is that I don't think there is value to obscuring a directory path from the application even if that is not how they access it. As a user, browsing to a directory and selecting a file certainly doesn't convey to me that the application wouldn't know where that file was (even if it accesses it via another path). It feels very much like an implementation detail due to how FUSE works, and if so, it would be nice to find a workaround for applications to exist with stronger sandboxing even for this use case.
The text was updated successfully, but these errors were encountered: