Can you add unit tests for he windows paths?

It won't matter, since the mount paths are cleaned on L39 (cleaned := filepath.Clean(vol.MountPath)), which means that all the /s will be replaced by \.

My understanding is we still need to rely on sorting to ensure that nested directories do come at some point after their parent directories right?

They're still sorted (L45), but now we're checking at L71-77 if that directory was seen already.

For example, let's say we have \dir\nested\foo, \dir\nested2, \dir\nested. This will be sorted to \dir\nested, \dir\nested2, \dir\nested\foo. Being the first one, \dir\nested is added to retval. The second one, doesn't match any previous mountpoint (\dir\nested2 doesn't have the \dir\nested\ prefix), it is then added to retval. FInally, \dir\nested\foo has the prefix \dir\nested\, so it's skipped.

The sort is still useful, it still makes sure that \dir\nested\foo is sorted after \dir\nested, which will mean that \dir\nested\foo will be treated as an already seen mountpoint.

Is there an example where Windows paths have a different ordering than Linux? So far this example looks the same.

Indeed, the ordering I've written here for Windows is wrong, it was supposed to be: \dir\nested, \dir\nested-vol, \dir\nested.vol, \dir\nested2, \dir\nested\double (2 has a smaller ascii value than \)

@joelsmith @jsafrane @sjenning do you remember why we have this special case for double nested where we don't use the full path?

I thought it could have been related to supporting mounting a configmap/secret as file, but it doesn't seem like that's supported: #61545

I dug into this, we really need only 1 level of nested mounts here. It's not obvious from the code, I had to create a pod with three Secrets mounted into each other:

apiVersion: v1
kind: List
items:
- apiVersion: v1
  kind: Secret
  data:
    secret: bXkgc2VjcmV0Cg==
  metadata:
    name: first
  type: Opaque
- apiVersion: v1
  kind: Secret
  data:
    secret: c2VjcmV0Cg==
  metadata:
    name: second
  type: Opaque
- apiVersion: v1
  kind: Secret
  data:
    secret: c2VjcmV0Cg==
  metadata:
    name: third
  type: Opaque
- apiVersion: v1
  kind: Pod
  metadata:
    name: busybox-pod
  spec:
    containers:
    - image: gcr.io/google_containers/busybox:latest
      name: busybox
      command: ["/bin/sh"]
      args: ["-c", "while sleep 3600; do true; done"]
      volumeMounts:
      - mountPath: /first
        name: first 
      - mountPath: /first/second
        name: second
      - mountPath: /first/second/third
        name: third
    restartPolicy: OnFailure
    volumes:
    - name: first
      secret:
        secretName: first
    - name: second
      secret:
        secretName: second
    - name: third
      secret:
        secretName: third

On the host, /var/lib/kubelet/pods/<uid>/ looks like this:

$ ls -l /var/lib/kubelet/pods/1fc8e54a-3997-4abe-b7dd-3319b433c0c4/volumes/kubernetes.io~secret/
drwxrwxrwt. 4 root root 120 Oct 18 08:35 first
drwxrwxrwt. 4 root root 120 Oct 18 08:35 second
drwxrwxrwt. 3 root root 100 Oct 18 08:35 third

$ ls -l /var/lib/kubelet/pods/1fc8e54a-3997-4abe-b7dd-3319b433c0c4/volumes/kubernetes.io~secret/first
drwxr-xr-x. 2 root root 40 Oct 18 08:35 second
lrwxrwxrwx. 1 root root 13 Oct 18 08:35 secret -> ..data/secret

$ ls -l /var/lib/kubelet/pods/1fc8e54a-3997-4abe-b7dd-3319b433c0c4/volumes/kubernetes.io~secret/second
lrwxrwxrwx. 1 root root 13 Oct 18 08:35 secret -> ..data/secret
drwxr-xr-x. 2 root root 40 Oct 18 08:35 third

• first/ contains an empty directory second, where the container runtime will bind-mount /var/lib/kubelet/pods/1fc8e54a-3997-4abe-b7dd-3319b433c0c4/volumes/kubernetes.io~secret/second
• second/ contains an empty directory third, where the container runtime will bind-mount /var/lib/kubelet/pods/1fc8e54a-3997-4abe-b7dd-3319b433c0c4/volumes/kubernetes.io~secret/third

Therefore, only one level of nesting is needed. Second (third, ...) level is brought from their respective pod-local volumes via bind mounts.

This isn't related to your change, but can you add a test case for triple nested volumes?

That case is already treated in the Big Pod case below.