-
Notifications
You must be signed in to change notification settings - Fork 28
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
Fix comparison. #742
base: develop
Are you sure you want to change the base?
Fix comparison. #742
Conversation
✅ be863c3 success - wakame-ci/rspec |
✅ be863c3 success - wakame-ci/cli/vdc-manage |
✅ be863c3 success - wakame-ci/cli/backup-cleaner |
✅ be863c3 success - wakame-ci/rpmbuild |
❌ be863c3 failure - wakame-ci/yumrepo/to-dropbox |
❌ be863c3 failure - wakame-ci/yumrepo/to-s3 |
find_loopdev(path) just seems to implement the -j option of losetup. (Maybe that option did not used to exist on losetup?) So something like this is an alternative:
|
|
|
|
|
|
|
|
This has more optimistic way than the current implementation. Is the strict checking really necessary? |
The code change looks good to me. Not sure what to think about the issues you bring up above about "already deleted" and "strict checking". (The old code should also have the same problem if the file is already deleted) (What do you mean by "more optimistic"?) In the bigger picture... I suspect that using kpartx and all these workarounds is not the best solution. Usually we only want to mount one partition, and losetup can do that by itself, if given the proper offset. Then we avoid using device-mapper and invoking kpartx udev rules, so we avoid potential problems from this behind-the-scenes complexity. But that is probably a bigger change than we want to do now. For reference, see the rambling comment in here, which I should probably edit soon: So for this little change: |
"strict checking" is just my personal point of view. The old code checks the file system identifier and the inode number that are derived from a target file, in turn my change only checks the file path. |
But it gets the identifier and inode number from the path with "stat = File.stat(path)", so maybe it is the same strictness. |
✅ c3e5334 success - wakame-ci/rspec |
✅ c3e5334 success - wakame-ci/cli/vdc-manage |
✅ c3e5334 success - wakame-ci/cli/backup-cleaner |
✅ c3e5334 success - wakame-ci/rpmbuild |
✅ c3e5334 success - wakame-ci/yumrepo/to-s3 |
✅ c3e5334 success - wakame-ci/yumrepo/to-dropbox |
✅ c3e5334 success - wakame-ci/dummy.smoke |
❌ c3e5334 failure - wakame-ci/vz.smoke |
❌ c3e5334 failure - wakame-ci/lxc.smoke.allowed-failure |
✅ c3e5334 success - wakame-ci/kvm.smoke.lb |
✅ c3e5334 success - wakame-ci/kvm.smoke |
Why did |
✅ c3e5334 success - wakame-ci/rspec |
✅ c3e5334 success - wakame-ci/cli/vdc-manage |
✅ c3e5334 success - wakame-ci/cli/backup-cleaner |
✅ c3e5334 success - wakame-ci/rpmbuild |
✅ c3e5334 success - wakame-ci/yumrepo/to-s3 |
✅ c3e5334 success - wakame-ci/yumrepo/to-dropbox |
✅ c3e5334 success - wakame-ci/dummy.smoke |
❌ c3e5334 failure - wakame-ci/vz.smoke |
❌ c3e5334 failure - wakame-ci/lxc.smoke.allowed-failure |
✅ c3e5334 success - wakame-ci/kvm.smoke.lb |
✅ c3e5334 success - wakame-ci/kvm.smoke |
✅ 6cef641 success - wakame-ci/rspec |
✅ 6cef641 success - wakame-ci/cli/vdc-manage |
✅ 6cef641 success - wakame-ci/cli/backup-cleaner |
✅ 6cef641 success - wakame-ci/rpmbuild |
✅ 6cef641 success - wakame-ci/yumrepo/to-s3 |
✅ 6cef641 success - wakame-ci/yumrepo/to-dropbox |
✅ 6cef641 success - wakame-ci/dummy.smoke |
❌ 6cef641 failure - wakame-ci/vz.smoke |
❌ 6cef641 failure - wakame-ci/lxc.smoke.allowed-failure |
✅ 6cef641 success - wakame-ci/kvm.smoke.lb |
✅ 6cef641 success - wakame-ci/kvm.smoke |
#741