-
-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential regression in the document portal #1234
Comments
I installed Workbench (via Software) and launched it, but had to install the Rust extensions. I installed the extensions, then closed Workbench, restarted it, and no reproduction. I uninstalled by deleting data (via Software), except Rust extensions. I reinstalled it and no reproduction. |
I can't reproduce with these steps. I run xdg-document-portal 1.18.2 from Fedora. |
Above I saved the project. When I re-open it and press "Run" I can reproduce. |
The error:
|
I can also reproduce by saving the project. Notice that the path to the folder is |
@hfiguiere ha yes of course I forgot the steps to save the project and reopen to make use of the document portal. I updated the instructions. Thanks for catching. I haven't been able to reproduce the problem with the previous version of xdg-desktop-portal (1.18.0) |
The funny thing is that while I get the error, if I flatpak enter I can access all the files in question. |
The fatal call is in cargo:
This mean it has been unlinked. |
All you need is to use this small reproducer: #include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
int main(int, char**) {
char cwd[4096];
char* r = getcwd(cwd, 4096);
printf("CWD = %s\n", r);
return 0;
} It will print |
|
Issue flatpak#1234 Signed-off-by: Hubert Figuière <[email protected]>
This fixes issue flatpak#1234 fuse_lowlevel_notify_inval_entry() will invalidate directories too, which is a problem as it invalidate the current workdir directory. So now we don't invalidate them and will let the kernel deal with it. This is consistent with the passthrough_hp example from fuse. Signed-off-by: Hubert Figuière <[email protected]>
This fixes issue flatpak#1234 fuse_lowlevel_notify_inval_entry() will invalidate directories too, which is a problem as it invalidate the current workdir directory. So now we don't invalidate them and will let the kernel deal with it. This is consistent with the passthrough_hp example from fuse. Signed-off-by: Hubert Figuière <[email protected]>
This fixes issue flatpak#1234. This is a followup from flatpak#1190. fuse_lowlevel_notify_inval_entry() will invalidate directories too, which is a problem as it invalidate the current workdir directory. So now we don't invalidate them and will let the kernel deal with it. This is consistent with the passthrough_hp example from fuse. Signed-off-by: Hubert Figuière <[email protected]>
This fixes issue flatpak#1234. This is a followup from flatpak#1190. fuse_lowlevel_notify_inval_entry() will invalidate directories too, which is a problem as it invalidate the current workdir directory. So now we don't invalidate them and will let the kernel deal with it. This is consistent with the passthrough_hp example from fuse. Signed-off-by: Hubert Figuière <[email protected]>
This works around issue flatpak#1234. This is a followup from flatpak#1190. fuse_lowlevel_notify_inval_entry() will invalidate directories too, which is a problem as it invalidate the current workdir directory. So now we don't invalidate them and will let the kernel deal with it. This is consistent with the passthrough_hp example from fuse. But this still make the directory being held for longer than necessary. Signed-off-by: Hubert Figuière <[email protected]>
This works around issue flatpak#1234. This is a followup from flatpak#1190. fuse_lowlevel_notify_inval_entry() will invalidate directories too, which is a problem as it invalidate the current workdir directory. So now we don't invalidate them and will let the kernel deal with it. This is consistent with the passthrough_hp example from fuse. But this still make the directory being held for longer than necessary. Signed-off-by: Hubert Figuière <[email protected]>
Operating System
Fedora
XDG Desktop Portal version
1.18
XDG Desktop Portal version (Other)
1.18.2
Desktop Environment
GNOME
Desktop Environment (Other)
No response
Expected Behavior
rust works fine in the document portal
Current Behavior
rustc throws fs related errors such as
or
Steps to Reproduce
If you reproduce the issue, it will happen until reboot.
A reboot might solve it
Anything else we should know?
Reproducible with: 1.18.2
Not reproducible with 1.18.0
The text was updated successfully, but these errors were encountered: