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

bundler on Windows - permission denied #5421

Closed
ahorek opened this Issue Nov 6, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@ahorek
Copy link
Contributor

ahorek commented Nov 6, 2018

Environment

jruby 9.2.1.0 (2.5.0) 2018-11-06 7b14404 Java HotSpot(TM) 64-Bit Server VM 25.181-b13 on 1.8.0_181-b13 +jit [mswin32-x86_64]

Expected Behavior

unfortunatelly 7b14404 breaks bundler on windows, sorry I didn't catch it earlier!

Actual Behavior

bundle update
Fetching https://github.com/rails/rails
The dependency byebug (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for java but the dependency is only for ruby. To add those platforms to the bundle, run bundle lock --add-platform ruby.
There was an error while trying to write to
C:/Users/pdaho/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions.
It is likely that you need to grant write permissions for that path.

@ahorek

This comment has been minimized.

Copy link
Contributor Author

ahorek commented Nov 6, 2018

Permission denied - C:/Users/pdaho/AppData/Local/Temp/bundler-compact-index-20181107-11968-vsnwak/versions or C:/Users/pdaho/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions
org/jruby/RubyFile.java:1120:in `rename'
/jruby/lib/ruby/gems/shared/gems/bundler-1.16.5/lib/bundler/vendor/fileutils/lib/fileutils.rb:469:in `block in mv'
/jruby/lib/ruby/gems/shared/gems/bundler-1.16.5/lib/bundler/vendor/fileutils/lib/fileutils.rb:1461:in `block in fu_each_src_dest'
/jruby/lib/ruby/gems/shared/gems/bundler-1.16.5/lib/bundler/vendor/fileutils/lib/fileutils.rb:1477:in `fu_each_src_dest0'
/jruby/lib/ruby/gems/shared/gems/bundler-1.16.5/lib/bundler/vendor/fileutils/lib/fileutils.rb:1459:in `fu_each_src_dest'
/jruby/lib/ruby/gems/shared/gems/bundler-1.16.5/lib/bundler/vendor/fileutils/lib/fileutils.rb:458:in `mv'
/jruby/lib/ruby/gems/shared/gems/bundler-1.16.5/lib/bundler/compact_index_client/updater.rb:72:in `block in update'
/jruby/lib/ruby/gems/shared/gems/bundler-1.16.5/lib/bundler/shared_helpers.rb:118:in `filesystem_access'
/jruby/lib/ruby/gems/shared/gems/bundler-1.16.5/lib/bundler/compact_index_client/updater.rb:71:in `block in update'
/jruby/lib/ruby/stdlib/tmpdir.rb:89:in `mktmpdir'

@ahorek ahorek changed the title atomic fix breaks bundler on Windows bundler on Windows - permission denied Nov 7, 2018

@ahorek

This comment has been minimized.

Copy link
Contributor Author

ahorek commented Nov 7, 2018

ok, this is weird, bundler shares C:\Users\user.bundle\cache\compact_index* path

1/ clean this path
2/ run bundler on jruby
this works, but

1/ clean this path again
2/ run bundler on mri
3/ run bundler on jruby
this fails

it looks like these files are created with a different set of permissions and jruby's new rename implementation can't replace files that were generated with mri

so 7b14404 didn't break it

@ahorek

This comment has been minimized.

Copy link
Contributor Author

ahorek commented Nov 7, 2018

i'm not sure why's oldFile.renameTo(dest) failing... there're probably some differences with permissions, but I didn't find any.
there's only a difference with CR/LF line endings, which is probably unrelated.

@enebo enebo added this to the JRuby 9.2.2.0 milestone Nov 7, 2018

@enebo

This comment has been minimized.

Copy link
Member

enebo commented Nov 7, 2018

@ahorek I just audited how this worked in 9.2 and we bailed upon detecting files were in different FS. Not sure if I see this or not locally but 44bd17d logic was bypassing that final attempt and the raise would make it into a copy. I will see if I can repro this on windows but a Platform.IS_WINDOWS restoring that check may be simplest workaround barring some more analysis.

@ahorek

This comment has been minimized.

Copy link
Contributor Author

ahorek commented Nov 7, 2018

Files.move(oldPath, destPath, StandardCopyOption.ATOMIC_MOVE);

should throw AtomicMoveNotSupportedException

in this case the file is acually moved correctly, but it fails afterwards at
https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/RubyFile.java#L1120

you should be able to simulate it like this
run bundler on mri
run bundler on jruby
(I choose the mail gem's repository https://github.com/mikel/mail)
if you run bundler only on jruby it works fine without any patches

I have a workaround
#5425

but could you review these lines? I think if there's no exception in Files.move, we shouln't be trying to rename old file that doesn't exist anymore because it was already moved
https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/RubyFile.java#L1110-L1120

@enebo

This comment has been minimized.

Copy link
Member

enebo commented Nov 7, 2018

@ahorek examine my PR. I think we have already successfully moved the file so why do it a second time?

@ahorek

This comment has been minimized.

Copy link
Contributor Author

ahorek commented Nov 7, 2018

yeah, I thought it's just a remnant from the old logic...

@enebo enebo closed this in #5429 Nov 7, 2018

enebo added a commit that referenced this issue Nov 7, 2018

Merge pull request #5429 from jruby/fix_file_rename
Attempt to fix #5421 windows oddity where some times a rename during bundle…
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.