[6.x] Set FileStore file permissions only once

[netpok]

Follow up to #32841:

This modifies some of the behaviour in 61b5aa1
From pull request #31579

That change was intended to make it easier for multiple OS users to read/write the same cached values when using the FileStore driver. However, the change introduced a subtle bug. Suppose we have the following situation:

One user (say www-data) puts a value in the cache.
2 Some time later but before the value from (1) has expired, another user (say ubuntu) attempts to update the value written in (1).
This will fail irrespective of what $filePermission value is configured for FileStore because:

after (1), the owner of the file on disk is www-data
FileStore will attempt to call FileSystem#chmod on this file
FileSystem#chmod will fail because the OS will prevent ubuntu from changing the file permissions of a file owned by www-data
In short, the $filePermission option is not working as intended when two users try to write to the same cache key.

This PR solves the problem by checking the permissions first so it only tries to set it once. As a bonus on multiple writes the check first aproach is significantly faster (only the chmod was measured).

[GrahamCampbell]

Have you tested this actually works in the way you claim, and that the process is actually able to change the permissions?

[netpok]

Yes, it is tested. It should work based on logic but I also tested it manually.

• Since the permission is set when the file is created the same process naturally can set the permissions.
• When an other process tries to access it already has the correct permissions so there is no need to change it.
• When the permissions cannot be changed (because it was created by an other user before the permission feature was enabled) it emits the warning which is expected in this scenario and makes more sense then silently ignore the error.

---

Also I can see future problems about this feature as it accepts the permission in octal form so passing 'permission' => 666 results in a problem since it should be 'permission' => 0666.

[louismrose]

Thanks for fixing this, @netpok. I've tested your approach for my use case, and it works well. The original problem that I described in #32841 is fixed by this issue.