assets:install should keep ctime/mtime when in copy mode #54327
Comments
|
@zerkms: How do you retrieve the "ctime/mtime" values? As far as I know, files are timestamped when you pull them from Git, and they don't retain their original timestamps. Wouldn't this result in differences depending on the build time? Regarding caching, an 'immutable' cache header + long duration represents imho a better approach for caching static assets than LastModified (only), as they are versioned and never change afterwards. And i'm not sure i'd want a deployment script to mess with files metadata, this could have other side effects. Another solution could be to use hash-based ETags, removing the need for timestamps ? Some links about immutable/best practices : |
whatever it is currently in the filesystem.
It's fine, at least it will be the same everywhere.
This is controversial: deployment scripts deal with files - be it files contents, names, or metadata - I don't see any difference.
I know how caching in http works and how to workaround the problem. My suggestion is to not create problems in the very first place so that you didn't need to bring even more configuration to solve it. Nonetheless, I suggest to NOT discuss "the best practices" of how it should be done otherwise. My suggestion is - would the symfony team consider it, or not? |
|
I apologize if my message caused any offense; that was never my intention. I have recently dedicated some time to researching this topic and shared those bookmarks with the sole hope that they might be of interest to anyone reading this issue. |
|
IMHO, this concern doesn't belong to this command. We don't have mtime to keep track of. This does it (using concurrency to be a bit faster than a simple loop): git ls-tree -r --name-only HEAD | xargs -I {} -P $(nproc) bash -c '
filename="$1"
commitDate=$(git log -1 --format="%ai" -- "$filename")
if [ -n "$commitDate" ]; then
touch -d "$commitDate" "$filename"
fi
' _ {} |
How do you know that? It's not symfony's domain of responsibility to know how and where the source code retrieved from :-) Anyway, |
|
Why would we when I just gave a nice solution? |
it's a workaround, not a solution: you could have copied the assets with a bash scripts too, but instead there is command for that. So, why would the command retain names, and content, but drop metadata? Any particular reason to NOT keep metadata? |
|
The root cause is that in |
…oring directories (xabbuh) This PR was merged into the 5.4 branch. Discussion ---------- [Filesystem] preserve the file modification time when mirroring directories | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | Fix #54327 | License | MIT Commits ------- d232026 preserve the file modification time when mirroring directories
|
Ah, thanks for digging this @xabbuh! |
Description
Creation/last modification time of the web assets is used by web servers in the
Last-Modifiedheader.Hence if you have multiple instances of the application which had their
assets:installrun at different times - depending on what instance you hit - you may receive different values which would confuse the web server (asLast-Modifiedmust match theIf-Modified-Sinceexactly) and it would return http 200 and entire asset, instead of http 304.Example
none
The text was updated successfully, but these errors were encountered: