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

File push with ..-ending src behaves unexpectedly #1808

Closed
ppepos opened this issue Mar 18, 2025 · 0 comments · Fixed by #1809
Closed

File push with ..-ending src behaves unexpectedly #1808

ppepos opened this issue Mar 18, 2025 · 0 comments · Fixed by #1809
Assignees
Milestone

Comments

@ppepos
Copy link

ppepos commented Mar 18, 2025

Required information

  • Distribution: Arch
  • Distribution version: lol
  • The output of "incus info" or if that fails:
    • Kernel version: 6.13.6-arch1-1
    • LXC version: 6.0.3-1
    • Incus version: 6.10.1
    • Storage backend in use: btrfs

Issue description

Pushing a directory ending in .. does not behave as I would expect it to. I would expect the following to move the parent directory inside the /opt/target directory but it insteads copies it to the /opt directory.

incus file push -r .. /opt/target

Steps to reproduce

set -x

mkdir -p dir
touch dir/a
incus launch images:ubuntu/24.04 u1
incus launch images:ubuntu/24.04 u2

incus exec u1 -- mkdir -p /opt/target
incus file push -r dir u1/opt/target/.
incus exec u1 -- find /opt

incus exec u2 -- mkdir -p /opt/target
cd dir/
incus file push -r .. u2/opt/target/.
cd ../
incus exec u2 -- find /opt

incus rm u1 --force
incus rm u2 --force

Although not equivalent, in u2, I believe dir should be inside target but it is instead at /opt/dir.

I am not certain if this will be considered a bug or not but since I hit it and had to fiddle a bit to find the issue, I figured I'd let our benevolent dictators decide. ;)

Thanks.

PS: The issue template is not working anymore, github did you dirty.

stgraber added a commit to stgraber/incus that referenced this issue Mar 18, 2025
Not too sure why we were using Split rather than Dir given we were
discarding the Base part of the path. But it looks like Split gets a bit
confused by relative parent paths (..) whereas Dir doesn't.

Closes lxc#1808

Signed-off-by: Stéphane Graber <[email protected]>
@stgraber stgraber self-assigned this Mar 18, 2025
@stgraber stgraber added this to the incus-6.11 milestone Mar 18, 2025
stgraber added a commit to stgraber/incus that referenced this issue Mar 18, 2025
When going through either .Split() or .Base(), a source path of ".." is
incorrectly treated as an empty source directory and so processed the
same as ".".

This is obviously incorect behavior which then leads to files landing in
the wrong directory on the server side.

I couldn't find a good way with pure filepath calls to handle this, so
instead we've got to hardcode the logic for the parent paths.
Any path containing a separator (/) are handled correctly though.

Closes lxc#1808

Signed-off-by: Stéphane Graber <[email protected]>
stgraber added a commit to stgraber/incus that referenced this issue Mar 18, 2025
When going through either .Split() or .Base(), a source path of ".." is
incorrectly treated as an empty source directory and so processed the
same as ".".

This is obviously incorect behavior which then leads to files landing in
the wrong directory on the server side.

I couldn't find a good way with pure filepath calls to handle this, so
instead we've got to hardcode the logic for the parent paths.
Any path containing a separator (/) are handled correctly though.

Closes lxc#1808

Signed-off-by: Stéphane Graber <[email protected]>
stgraber added a commit that referenced this issue Mar 28, 2025
When going through either .Split() or .Base(), a source path of ".." is
incorrectly treated as an empty source directory and so processed the
same as ".".

This is obviously incorect behavior which then leads to files landing in
the wrong directory on the server side.

I couldn't find a good way with pure filepath calls to handle this, so
instead we've got to hardcode the logic for the parent paths.
Any path containing a separator (/) are handled correctly though.

Closes #1808

Signed-off-by: Stéphane Graber <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants