Skip to content

[Process] Fix Permission Denied error when writing sf_proc_00 lock files on Windows #37461

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

Merged
merged 1 commit into from
Jul 6, 2020
Merged

[Process] Fix Permission Denied error when writing sf_proc_00 lock files on Windows #37461

merged 1 commit into from
Jul 6, 2020

Conversation

JasonStephensTAMU
Copy link
Contributor

Q A
Branch? 3.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets Fix #37294
License MIT
Doc PR

Passes current Process unit tests.

On Windows systems, a new set of sf_proc_## files are generated in the system temp directory for each WindowsPipes object. These files are removed when the WindowsPipes object is destroyed.

This avoids receiving a permission denied error when attempting to write to sf_proc_## files between multiple sites running as different users, when the users do not have permissions to modify each others files.

Changes

  • [Process] WindowsPipes always creates new sf_proc_## files in constructor
  • [Process] WindowsPipes removes its sf_proc_## files in destructor

Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I updated the implem)

@nicolas-grekas
Copy link
Member

Thank you @JasonStephensTAMU.

@nicolas-grekas nicolas-grekas merged commit c0181c7 into symfony:3.4 Jul 6, 2020
@JasonStephensTAMU
Copy link
Contributor Author

@nicolas-grekas Thanks, and I apologize for the lack of communication over the weekend, It was Independence day weekend in the states.

To answer your question in the review: I began working on some code that implemented your suggestion, I hadn't yet settled on the actions to take if/when unlinking the lock file succeeds.

With the current changes, does the test ProcessTest::testGetExitCodeIsNullOnWhenStartingAgain fail?

I attempted the same change, and after seeing the failed test I worked towards the changes that were initially submitted in the PR, though it may just be my machine.

@nicolas-grekas
Copy link
Member

@JasonStephensTAMU no worries. Not sure what you about testGetExitCodeIsNullOnWhenStartingAgain: tests are green on appveyor. Dunno what to tell you next :)

@JasonStephensTAMU
Copy link
Contributor Author

@nicolas-grekas Ah, must be just on my machine. All good, carry on!

@JasonStephensTAMU JasonStephensTAMU deleted the ticket_37294 branch November 8, 2021 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants