Simply doesn't work with copy task

[ts-web]

Shouldn't this work?:

Gruntfile:

// ...
grunt.initConfig({
    copy: {
        stuff: {
            files: {
              'dist/file.txt': 'app/file.txt'
            }
        }
       //...
    }
  });
// ...

But running grunt newer:copy:stuff copies it every time.

Another variant also does the same thing:

// ...
        stuff: {
            src: 'app/file.txt',
            dest: 'dist/file.txt'
        }

What is going on?
I'm on Windows 7 with node v0.12.2, [email protected], [email protected], [email protected], [email protected]

[MeoMix]

👍 It doesn't work because copying doesn't cause 'dest' to update its last modified time. If you go into 'dest' and edit the file then it works as expected.

[MeoMix]

@ts-web Here, I forked grunt-contrib-copy to add support for this: https://github.com/MeoMix/grunt-contrib-copy/blob/master/tasks/copy.js

Now if you call copy with:

options: { mtimeUpdate: true }

it will force copied files to update their modified time so that grunt-newer will work as expected.

[ts-web]

@MeoMix thanks for the explanation. I'm still confused about what's going on though.

Does 'newer' check the mtime of both the src and dest files before it decides whether to run the task? And if the src mtime <= the dest mtime, then it should not run? But if src mtime > dest mtime, then it should run? Is that how it works?

If that's how it works, then 'copy' should not update the mtime to the time of the operation -- it should retain the src file's mtime. That way, both mtimes will be the same, and it should not run again. And if the src file gets modified later, then src mtime will be greater than dest mtime, and it should run.

So it seems to me that if copy and newer work in the way I have described, then things should work. But I suspect that newer does not just look at file mtimes. How does it work exactly, do determine whether to run the task?

@MeoMix or did you mean to say that copying does cause 'dest' to update its last modified time [to the time of the copy operation]? Other than that I don't understand why it wouldn't be working.

Newer's readme says that it will run when the source files are "newer than the dest files". Is this referring to mtime or creation time?

A little clarification would help me and whoever else may have this same problem and come across this thread.

[MeoMix]

Hey,

My understanding of grunt-newer is pretty limited because I just started using it about an hour before posting here yesterday, but here's what I know:

• It keeps a "cache" folder underneath its installed module.
• The "cache" folder keeps track of each task which has ran and stores a file with a DateTime inside of it. The DateTime is the last ran time of the task.
• Copying does not update the mtime of a file.

So, if you have fileA which was last modified at time 12345 and copy it to directory "/foo" then fileACopy will have a last modified time of 12345, but the cache will have a stored time of 777888.

Since 777888 is greater than 12345 subsequent runs of the task will believe that the file is still out-of-date.

By updating the mtime of the copied file we set its last modified time to 777999. This lets grunt-newer realize that no action is necessary.

[masi]

I've noticed the issue as well. There is another theory about the problem:

#86

[giovannipds]

Same problem here. I've tried using the option "timestamp" which is described in grunt-contrib-copy but it doesn't seem to work. I've put a testing repo here, if needed somehow: https://github.com/giovannipds/grunt-newer-copy-test.

[krnlde]

Any news on this? Our environment has to copy ~2000 files on each save, due to this bug. This is a huge performance impact, and also very bad for SSDs. How can I help?

[giovannipds]

An alternative is to use grunt-sync, not grunt-contrib-copy. With grunt-sync you don't even have to worry about using grunt-newer within.

Still, no news about it, unfortunately. =/

[krnlde]

Sounds great I'll have a look into it!

[giovannipds]

@krnlde 👍 ;)