I agree this is an issue and we should not be removing volumes this way.

@mheon PTAL

I would have to double-check, but I believe this is a duplicate of Docker behavior, and as such I don't think we can change it. And even if we could, I'm not sure we should.

If you were two have two volumes, ab and abc, and podman volume rm a - you'd get an error about an ambiguous name. But this scenario, a is a fully qualified name, we will remove it happily - and I think changing that is also very unexpected behavior. Any sort of Bash script that operates on Podman, for example, will expect that podman volume rm $name will always work, so long as $name is the full name of the volume, even if there's a second volume with $name as a prefix to its own name. Breaking the assumption that removal by full name always works seems dangerous.

The issue is if you only have one volume named abc, and do podman volume rm a it is removing abc, as I understand it, which seems very dangerous.

Only once a is gone. Once a is gone, we will remove abc as long as there are no other volumes whose names start with a; otherwise we error. Unambiguous partial names are allowed.

Yup, but I find that surprising and likely to cause volumes to be removed by accident.

And I see little upside in this other then perhaps Docker does it this way.

As the reporter states it easy enough to do podman volume rm a<tab>

Docker has different behaviour

$ docker volume ls
DRIVER    VOLUME NAME
$ docker volume create x
Error response from daemon: create x: volume name is too short, names should be at least two alphanumeric characters
$ docker volume create xx
xx
$ docker volume create xxa
xxa
$ docker volume rm xx
xx
$ docker volume rm xx
Error response from daemon: get xx: no such volume
$ docker volume rm xxa
xxa
$

Tested with docker 27.1.2

More info about the system:

$ docker version
Client:
 Version:           27.1.2
 API version:       1.46
 Go version:        go1.23.0
 Git commit:        1.fc42
 Built:             Wed Aug 21 00:00:00 2024
 OS/Arch:           linux/arm64
 Context:           default

Server:
 Engine:
  Version:          27.1.2
  API version:      1.46 (minimum version 1.24)
  Go version:       go1.23.0
  Git commit:       1.fc42
  Built:            Wed Aug 21 00:00:00 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.7.21
  GitCommit:        1.fc42
 runc:
  Version:          1.1.12
  GitCommit:        
 tini-static:
  Version:          0.19.0
  GitCommit:        
$ rpm -qf /usr/bin/docker
docker-cli-27.1.2-1.fc42.aarch64
$ rpm -q moby-engine
moby-engine-27.1.2-1.fc42.aarch64
$ rpm-ostree status
State: idle
warning: Failed to query journal: couldn't find current boot in journal
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:rawhide
                   Digest: sha256:b49001cc46b33e163c44eef55f26a722acf21d1bc0dceac3dac99bcc9a97f34e
                  Version: 42.20240830.91.0 (2024-08-30T14:00:28Z)

this seems valid then ... lets tidy it up ?

Could still be considered a breaking change since we're altering behvaior on volume rm rather significantly. @Luap99 Thoughts?

Well other commands behave sort of similar with partial ids. The difference in volume is that there is only one Name field and not Name and ID as separate things so the logic here got conflated into the same things which is not nice.

Of course if there is an exact match we must remove that is clear but if docker doesn't remove partial name matches then I think we should not either. Although I would compare this behavior against an actual ID (anonymous volume).

As far as breaking people, I am not sure that happens much in practice. Scripts should use the full name anyway and would need to get out of their way to rely on the partial lookup and for interactive use shell completion should be good enough.

Apologies if this isn't the place to ask, but would this be a good beginner issue? I'm interested to look into it if it isn't already being worked on by someone else.

@zackattackz You can try for sure, I don't think it is to easy as you have to find the right places where to logic applies and the compare this against the docker behavior but it should not be super difficult either I guess.

@Luap99
Yeah it probably would be better if someone who's already familiar with the code worked on it. But I figured it could be a good opportunity to get some familiarity with the code base. If it's not urgent I'd like to try :)

PR made at #24027

A friendly reminder that this issue had no activity for 30 days.