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 provisioner: .sock "files" are tried to be copied #2872

Closed
vemv opened this issue Oct 27, 2015 · 5 comments
Closed

File provisioner: .sock "files" are tried to be copied #2872

vemv opened this issue Oct 27, 2015 · 5 comments
Labels
enhancement pre-1.0 provisioner/file wontfix Out of scope/alignment with the project, or issue is expected, intended behavior

Comments

@vemv
Copy link

vemv commented Oct 27, 2015

If a directory I intend to copy contains a socket (e.g. "/var/rails/testapp/tmp/sockets/unicorn.sock"), the File Provisioner will try to copy it, failing the build.

Smart behavior would be skipping these .sock files I think?

Cheers - Victor

@cbednarski
Copy link
Contributor

@vemv Thanks for the report! You've asked the file provisioner to do something and it can't, so it errors. This is preferable to the file provisioner silently ignoring things.

I think it is more straightforward to resolve this either by making sure there are no socket files in your upload directory, or by creating a tarball with the files you want to upload.

We do have include / exclude filtering in some other packer features but this turns out to be very confusing for people to use because you cannot inspect the list of files in advance.

@vemv
Copy link
Author

vemv commented Oct 29, 2015

As I see it, a socket is a non-file. If I ask to copy a directory, then non-files are irrelevant and safe to skip silently (or semi-silently by logging the incident but not failing the task).

Feel free to close the issue if you disagree.

Cheers - Victor

@dave2
Copy link
Contributor

dave2 commented Dec 6, 2015

I'd disagree with this. tar knows how to store such files (as nodes). That sockets have nothing to read from when something is not listening doesn't make it any less a file in how it's accessed. They are opened/read/written/closed exactly like files, but happen to be backed by a device or socket. I don't think that makes them "non-files" at all, not in a strict filesystem sense.

@mwhooker
Copy link
Contributor

I don't think there's a good solution we can implement before 1.0. I recommend using existing tools to filter the file before uploading

@mwhooker mwhooker added pre-1.0 wontfix Out of scope/alignment with the project, or issue is expected, intended behavior labels Jan 30, 2017
@mwhooker
Copy link
Contributor

related to #1811

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement pre-1.0 provisioner/file wontfix Out of scope/alignment with the project, or issue is expected, intended behavior
Projects
None yet
Development

No branches or pull requests

4 participants