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

Bunled scripts file mode not preserved #135

Open
dskrvk opened this issue Jan 22, 2018 · 7 comments
Open

Bunled scripts file mode not preserved #135

dskrvk opened this issue Jan 22, 2018 · 7 comments

Comments

@dskrvk
Copy link

dskrvk commented Jan 22, 2018

I recently upgraded from v. 0.7.9 to 0.10.1 and faced an issue where a bunch of scripts stored under src/pack/ lost some of their "execute" flags after sbt pack copied them to the output directory. Specifically, the mode changed from 0775 to 0764. Is this done on purpose?

@xerial
Copy link
Owner

xerial commented Jan 23, 2018

For bin folder files, sbt-pack adds x, but for the other resource files, I think sbt-pack should preserve the file permission.

Which version of sbt are you using? sbt 0.13 or 1.1?

@xerial
Copy link
Owner

xerial commented Jan 23, 2018

If this might be related sbt/io#76, using sbt 1.1 will resolve the problem.

@dskrvk
Copy link
Author

dskrvk commented Jan 23, 2018

I was on sbt 1.0.4, but switching to 1.1.0 and doing a clean pack produces the same result.

@xerial
Copy link
Owner

xerial commented Jan 23, 2018

It looks like a bug of sbt-io, which calls setExecutable(true), which only sets x (executable) to the file owner. I'll file a bug ticket.

@eed3si9n
Copy link

@dskrvk Are you saying that

  1. the source files stored in src/pack/ has lost their permissions, or
  2. the target files created by pack used to have 0755 under sbt 0.13, but now became 0764 in sbt 1.0.4?

@xerial
Copy link
Owner

xerial commented Jan 23, 2018

At least sbt-pack 0.7.9 was using IO.copyDirectory (same with sbt-pack 0.10.1):

IO.copyDirectory(from, to, overwrite = true, preserveLastModified = true)

@dskrvk
Copy link
Author

dskrvk commented Jan 23, 2018

@eed3si9n the 1st option. I would expect the original permissions to be preserved.

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