-
Notifications
You must be signed in to change notification settings - Fork 64
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
8dot3name short name creation not persisted #507
Comments
@nbrinks Hi, thanks for bringing up this Issue. We'd love to learn more about your use case. Can we ask why you're using short names in containers? And do you know when this feature stopped working for you? |
@ntrappe-msft, We have some legacy build systems that use hardcoded short names. We are attempting to containerize our build environments. Our IT group has been making changes to the short name creation policy. Would changes to that have an impact on containers running with process isolation? |
@nbrinks Thanks for sharing. I'm waiting to hear back from a few other engineers about whether short names not persisting is expected or not. I'll provide an update as soon as I can. |
I should be able to provide an answer by the end of this week. I'm waiting on one other team to confirm that they're in agreement. |
Hi @nbrinks thanks for your patience. In summary, 8dot3 short names are not designed to be persisted across container layers. This is why setting the 8dot3 file name in one We'd recommend you do not use 8dot3 short names in containers. This behavior is intentional to prevent naming conflicts across layers. It's clear that we didn't do a good job of making this behavior obvious, and we're working to address this. |
@ntrappe-msft, thank you for the update. Unfortunately it's not practical for us to not use 8dot3 short names in this particular case. Fortunately the directory symbolic link appears to be a viable workaround. I appreciate the thoughtful investigation. |
I've just hit this issue too (different project from nbrinks) - we've got some automated machine setup and I thought setting the default I'm going to need to consider options here if this isn't a supported use case though - maybe we can ensure that all the shortnames prior to starting the process that relies on them ... Although I quite like @nbrinks' use of (EDIT: I've just done a stop/start cycle on a container that has shortnames and they appear to have been retained along with the default behavior of creating shortnames for new directories) |
@sxa What containers are you running? Also Server Core LTSC 2022? That's odd that 8dot3 short names are persisting for you. But going forward, I would recommend |
I've done a couple of of experiments on two server 2022 hosts ( Based on https://download.docker.com/win/static/stable/x86_64/ it looks like 27.1.1 was released on July 23rd so I initially wondered if I'd just set up the two machines before and after a change in the docker code was implemented ... However I've tried pulling the new zip from there on the non-working machine, replacing the files in windows/system32 with the new ones (Not sure what the correct upgrade process should be, but that seems reasonable) and it still isn't working on that machine even after a reboot and re-pull of the image so I'm still not 100% certain what the magic is on the working machine. I will also point out that the "working" machine has a separate docker data directory on an disk mounted as I'll look next week at setting up another clean machine to experiment with - maybe installing 27.1.1 on a clean system will work but I'm intrigued to know what the critical difference is - it definitely seems to be possible ... |
It looks like the 8dot3 shortname creating in the containers works as long is it's enabled on the file system that hosts the docker data. The 8dot3 setting is
@nbrinks Does that make a difference on your Windows 11 system? |
We'd still recommend against relying on 8dot3 names as they won't have support in future file systems. |
Describe the bug
Creating a short name in a layer doesn't appear to persist in subsequent layers, nor is the short name resolvable when starting the container.
To Reproduce
Given a
Dockerfile
such as the following:Build the image... e.g.
docker build -t shortname-example --no-cache .
The build output:
In the second
DIR P* /X
statement, the short names are gone.Expected behavior
It is expected that the short names persist so they will resolve in subsequent layers. Also, that the short names can be used in the final image.
Configuration:
Additional context
Strangely enough the short names used to resolve in the containers but suddenly stopped working recently. I haven't been able to pinpoint what exactly changed.
Currently using
mklink /D "C:/PROGRA~1" "C:/Program Files"
to work around this issue.The text was updated successfully, but these errors were encountered: