-
Notifications
You must be signed in to change notification settings - Fork 40
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
event on update_package_repository
#200
base: main
Are you sure you want to change the base?
Conversation
Does the rule trigger when the file does not exist?
|
@leogr The rule is not triggering when the file doesn't exist. So I made these changes: If the file doesn't exist:
If the file already exists:
|
Thank you, SGTM. Just, I'd like to get a second look from @FedeDP 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM too!
@FedeDP Cant we write the code like this. WDYT? Like writing defer statement before, bcz it executes after function return so it cleanups perfectly. Also tested with this code and rule triggers fine in both cases file exists and not exists
|
@GLVSKiriti even if more compact, i think it is less readable:
defer the remove when stat gives an error is super hard to read if one does not know the full context :) |
Thank you, @FedeDP, @leogr and @GLVSKiriti, for your feedback. I agree with @FedeDP; as this project continues to evolve and attract new contributors, it's beneficial to maintain readable code as much as possible. Clear code reduces confusion for newcomers, helping them understand it easily. |
_, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE, os.FileMode(0755)) | ||
if err != nil { | ||
return err | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not calling Close()
in this branch. Is it intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completely agree with this @leogr, we should close it first. While researching about it found this
-
Each open file is associated with a file descriptor, which is a reference to the open file If you remove the file without closing it, the file descriptor may still be in use.
-
It is quite often employed in Unix-only software to store temporary data:
- A temporary file is created
- It is then immediately removed on the filesystem (while being kept open).
- It is then used via the file descriptor for any amount of time.
- When the descriptor is closed, the filesystem finally reclaims the space the file's data were occupying.
Hence instead of creating space and other potential issues, its preferable to close file first.
@leogr @FedeDP Please provide your thoughts on this.
Signed-off-by: h4l0gen <[email protected]> commits squashed Signed-off-by: h4l0gen <[email protected]>
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Closing and reopening to trigger the CI |
@leogr: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@leogr: Reopened this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: h4l0gen The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area events
What this PR does / why we need it:
This PR triggers sandbox rule update package repository
Which issue(s) this PR fixes:
Fixes #120
Special notes for your reviewer: