Preserving asset file date when publishing #265

Let's consider that I have a project with the following layout:

A source folder src with an assets subfolder, e.g. for fonts.
A target folder pub.

When I want to publish my project on the web, I usually run:

raco pollen publish src pub
rsync pub/ user@server:dest/

As far as I can tell, raco pollen publish copies the files from my assets folder even if they have not changed, and does not preserve the date of the original files.
As a consequence, rsync thinks those files have changed and reuploads them every time.

Is there an option for raco pollen publish to ignore unchanged files, or to preserve their attributes?
If not, where should I look in the Pollen source code if I wanted to implement this feature?

Let's consider that I have a project with the following layout: * A source folder `src` with an `assets` subfolder, e.g. for fonts. * A target folder `pub`. When I want to publish my project on the web, I usually run: 1. `raco pollen publish src pub` 2. `rsync pub/ user@server:dest/` As far as I can tell, `raco pollen publish` copies the files from my `assets` folder even if they have not changed, and does not preserve the date of the original files. As a consequence, `rsync` thinks those files have changed and reuploads them every time. Is there an option for `raco pollen publish` to ignore unchanged files, or to preserve their attributes? If not, where should I look in the Pollen source code if I wanted to implement this feature?

Preserving the modification times during the publish operation might simply be a matter of adding a third optional #t argument to the call to copy-directory/files in this line of command.rkt. (See docs for copy-directory/files)

Minor point: I doubt that rsync is actually uploading the whole file. Rsync by default checksums any files it thinks are modified and only uploads the chunks that have actually changed. I would guess that what you are seeing as an upload is probably just rsync updating the modified-timestamp on the remote copy (more info). Still, I get that it’s nice not to see noise from updating files that haven't changed.

Preserving the modification times during the publish operation might simply be a matter of adding a third optional `#t` argument to the call to `copy-directory/files` in [this line of `command.rkt`](https://github.com/mbutterick/pollen/blob/816ce0f7af739b09dc0d64852d905ece24662bde/pollen/private/command.rkt#L289). ([See docs for `copy-directory/files`](https://docs.racket-lang.org/reference/Filesystem.html#%28def._%28%28lib._racket%2Ffile..rkt%29._copy-directory%2Ffiles%29%29)) Minor point: I doubt that `rsync` is actually uploading the whole file. Rsync by default checksums any files it thinks are modified and only uploads the chunks that have actually changed. I would guess that what you are seeing as an upload is probably just `rsync` updating the modified-timestamp on the remote copy ([more info](https://askubuntu.com/a/998619)). Still, I get that it’s nice not to see noise from updating files that haven't changed.

@otherjoel Thanks for the information.

Minor point: I doubt that rsync is actually uploading the whole file.

Yes. Maybe I was misinterpreting the output of rsync's --progress option.

@otherjoel Thanks for the information. > Minor point: I doubt that rsync is actually uploading the whole file. Yes. Maybe I was misinterpreting the output of rsync's `--progress` option.

The current default behavior seems best, because that way, all the files that result from raco pollen publish are treated uniformly.

I’d be open to adding this as a flag option for raco pollen publish. But I’d have to be persuaded that there’s a practical benefit. What @otherjoel says about rsync is true.

The current default behavior seems best, because that way, all the files that result from `raco pollen publish` are treated uniformly. I’d be open to adding this as a flag option for `raco pollen publish`. But I’d have to be persuaded that there’s a practical benefit. What @otherjoel says about `rsync` is true.

But I’d have to be persuaded that there’s a practical benefit.

I'm afraid I cannot provide more arguments to support my case.
I agree that my problem is more of a "cosmetic" nature, so I understand that it is not worth the effort.

> But I’d have to be persuaded that there’s a practical benefit. I'm afraid I cannot provide more arguments to support my case. I agree that my problem is more of a "cosmetic" nature, so I understand that it is not worth the effort.

Labels Milestones

Preserving asset file date when publishing #265