Skip to content
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

Screenshot: Please clarify ownership and lifetime of image file in documentation #1285

Open
schauveau opened this issue Feb 16, 2024 · 0 comments
Labels

Comments

@schauveau
Copy link

Operating System

any

XDG Desktop Portal version

1.18

XDG Desktop Portal version (Other)

No response

Desktop Environment

Other

Desktop Environment (Other)

No response

Expected Behavior

The current documentation of Screenshot https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Screenshot.html does not give any details about the ownership and lifetime of the generated image.

Simply speaking, who is responsible for deleting the image file and when? The fact that some "black magic" is happening with the document portal does not help.

Some implementations such as xdg-desktop-portal-wlr and xdg-desktop-portal-hyprland are currently using a fixed path (e.g. emersion/xdg-desktop-portal-wlr#298 ). I can only assume that it was done that way because the portal developer was not sure that all clients would remove the file so using a randomized name could lead to a large number of obsolete screenshot files filling up /tmp

Similarly, for a client developed using one of those faulty portal implementations, a developer could observe that the same filename is always reused and so that it should not be bothered to remove it after use.

I suspect that the expected behavior is that the file should be treated like most temporary files:

  • The portal implementation should randomize the filename to avoid race conditions and possible denials of services.
  • The client is the sole owner of the file and it is strongly advised to remove it after use to avoid filling up /tmp/

Conclusion: the documentation should be updated to enforce those rules.

Current Behavior

none

Steps to Reproduce

none

Anything else we should know?

No response

@schauveau schauveau added the bug label Feb 16, 2024
@github-project-automation github-project-automation bot moved this to Needs Triage in Triage Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Needs Triage
Development

No branches or pull requests

1 participant