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

qvm-copy restore to 4.1 functionality with "allow-symlinks" option #9667

Open
humanrights0218 opened this issue Dec 24, 2024 · 2 comments
Open
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.

Comments

@humanrights0218
Copy link

How to file a helpful issue

The problem you're addressing (if any)

The qvm copy functionality makes several breaking changes since 4.1 One such change was fixed in 4.2.2 with the +allow-all-names.

Currently, copying symlinks is still impossible. I think should be allowed with an 'allow-symlinks' options.

The current work around of using tar does not work in all use cases. For example, it could literally be impossible depending on free disk space let alone the amount of time it could take on large datasets.

The solution you'd like

"allow-symlinks" to enable the copying of symlinks between VMs

The value to a user, and who that user might be

Restore functionality back to 4.1. Makes copying possible where it is impossible now.

@humanrights0218 humanrights0218 added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. labels Dec 24, 2024
@andrewdavidwong
Copy link
Member

Related issues: #8581, #8332

Based on the discussion on #8581, it sounds like the devs have decided against doing this. However, I'll wait for confirmation that that's still the case before closing.

@jamke
Copy link

jamke commented Dec 26, 2024

I would vote for it.
I would love to have a reliable way of copying files as is, especially considering it would be opt-in option.
P.S. Has copying as is in Qubes OS R1.0-R4.0 ever caused any issues for anybody really?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Development

No branches or pull requests

3 participants