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

Permissions of files in working directory aren't preserved when copied #528

Closed
mkenigs opened this issue Jun 14, 2022 · 6 comments
Closed
Assignees

Comments

@mkenigs
Copy link
Contributor

mkenigs commented Jun 14, 2022

I have a file with permissions -rw------- in my working directory, but checking them in the VM they are -rw-r--r--

@fkorotkov
Copy link
Contributor

@edigaryev please correct me if I'm wrong but I think we never intended to preserve permissions for non dirty mode (aka when we mount the working directory). In other cases the CLI is just rsyncing/scping files inside the containers/VMs.

@mkenigs
Copy link
Contributor Author

mkenigs commented Jun 15, 2022

Oh okay, any reason not to use rsync -p?

@edigaryev
Copy link
Contributor

Oh okay, any reason not to use rsync -p?

Permissions are ignored because when you run your task in Cirrus Cloud, it uses Git to fetch your project directory, and Git is mostly unaware of file permissions, except for the executable bits.

Could you explain your use-case a bit better? More specifically, how do you deal with the same issue when running your tasks in the cloud, or do you only use Cirrus CLI locally?

@mkenigs
Copy link
Contributor Author

mkenigs commented Jun 17, 2022

That makes sense. Yeah you're right, I'm not doing it that way in the cloud; I was using an ssh key not checked into git, which I'll use an encrypted env var for in the cloud.

@fkorotkov
Copy link
Contributor

Good point, @edigaryev. Let's close it then. I also think there might be an issue with what kind of permissions to do when you run Cirrus CLI on Windows, for example.

@mkenigs
Copy link
Contributor Author

mkenigs commented Jun 17, 2022

(for posterity I'm guessing a local workaround is --dirty)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants