Skip to content
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

Retain file timestamps after copy #396

Closed
mcalmus opened this issue Jul 26, 2019 · 11 comments
Closed

Retain file timestamps after copy #396

mcalmus opened this issue Jul 26, 2019 · 11 comments

Comments

@mcalmus
Copy link

mcalmus commented Jul 26, 2019

  • Operating System:
  • Node Version:
  • NPM Version:
  • webpack Version:
  • copy-webpack-plugin Version:

Feature Proposal

See: angular/angular-cli#14003
It would be nice if files copied using the plugin could retain their original timestamps rather than getting the current date and time.

Feature Use Case

When a build is done it becomes very difficult to determine what has changed and when transferring files to another system the timestamp can not be relied upon for quick checks.

@alexander-akait
Copy link
Member

Please clarify what do you mean

@mcalmus
Copy link
Author

mcalmus commented Jul 26, 2019

When files are copied using the plugin the standard OS file copy is used. The resulting file has a date and time of when the copy was performed. It would be nice if the original file's timestamp were retained.

For example:

Say I have a file:

dir foo.png
02/21/2019 08:50 53,306 foo.png

When it's copied using the plugin it ends up as:
07/26/2019 10:00 53,306 foo.png

It would be nice if the copied file would retain the original February timestamp.

@alexander-akait
Copy link
Member

keeping original date/time is invalid because copied files was created/modified at 07/26/2019, i think it is unnecessary for this plugin, and very rare edge, you can create own plugin for this purpose

@adrianhuna
Copy link

I got around this problem by using rsync

rsync -a ~/path/to/project/src/assets/ ~/path/to/project/build/assets

@akx
Copy link
Contributor

akx commented Jan 15, 2020

We're using files copied by this plugin to upload a static site using aws s3 sync, which looks at file sizes and timestamps.
Currently all files get reuploaded on every sync, which is annoying.

I'll take a stab at implementing this, shouldn't be too hard.

@setzamora
Copy link

setzamora commented Mar 4, 2020

Same case here with Azure Storage, it would be great if we can retain the timestamp of each file so it would prevent it from being re-uploaded. This would speed up most CI/CD pipelines.

@alexander-akait
Copy link
Member

Feel free to send a PR

@akx
Copy link
Contributor

akx commented Mar 5, 2020

Feel free to send a PR

I have an open branch about this, but I got sidetracked. Perhaps I'll get something complete done this week or the next!

akx added a commit to akx/copy-webpack-plugin that referenced this issue Mar 9, 2020
akx added a commit to akx/copy-webpack-plugin that referenced this issue Mar 9, 2020
@akx akx mentioned this issue Mar 9, 2020
6 tasks
akx added a commit to akx/copy-webpack-plugin that referenced this issue Mar 9, 2020
akx added a commit to akx/copy-webpack-plugin that referenced this issue Mar 10, 2020
@DYefimov

This comment has been minimized.

@thw0rted
Copy link

thw0rted commented Apr 7, 2020

Just as a data point, this would help me.

I use the plugin to grab static assets from some libraries I'm using and put them in my dist directory during the build, then I use rsync or robocopy (depending on platform) to push the build directory to a staging server for testing. Right now, the sync program can't tell that the assets are the same every time, because the files in the build directory always have a newer timestamp than the ones that were last pushed to staging.

@alexander-akait
Copy link
Member

Let's close in favor #35, I think we will implement this in near future

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants