CODEWITHSUNDEEP
javawindowsdatetime
DSlomer64
DSlomer64

Reputation: 4283

Why does Java's `.dateLastModified` get truncated in some Windows 7 files?

I'm writing a backup program because Windows refuses to let me use its backup program for some reason. (I get an error code that I can report if need be.)

I only want to copy a source node file that is NEWER than a destination node file with the same name.

I found that, even though the last modified date in Windows Properties for two files showed to be identical, the source was almost invariably being copied--even though it's NOT newer.

enter image description here

enter image description here

Here are declarations:

File from_file = new File(from_name);
File to_file   = new File(to_name)

Here's what I finally found for two files in different folders with the same name.

The last 3 digits returned by .lastModified() may be NONzero for one file and ZERO for the other even though the dates shown in the Properties windows for the files appear identical.

My question is WHY would that be the case???

After much frustration and debugging, I have a workaround:

 destinationIsOlder = ((long)(from_file.lastModified()/1000)*1000 
                       > 
                       (long)(  to_file.lastModified()/1000)*1000);

But WHY do I have to do that? I.e., what is Windows doing? Should it do this? Is it a bug?

And what other similar evil awaits me?

I.e., should I divide by a larger integer than 1000?

(It's not the end of the world to copy a file that's technically and incorrectly reported to be a few milliseconds newer, but it's a lot of wear and tear on the drive if it happens for every single file in the source folder and subfolders!)

(I may have just stumbled onto why xcopy didn't do what I wanted, either.)

EDIT The times returned by the two calls shown above were

1419714384951 from from_file.lastModified() and

1419714384000 from to_file.lastModified(). Therefore, although identical, including displayed date and time, from_file is newer and thus, by rule, copied, but inappropriately.

Upvotes: 0

Views: 158

Answers (1)

adelphus
adelphus

Reputation: 10326

lastModified returns a long with millisecond precision - therefore the last 3 digits represent the fraction of a second.

Since the file properties dialog only displays time up to the second, the two files will show the same value.

Why are some zero and some non-zero? Lots of reasons. If the file is copied from somewhere else with only second precision, it will be zero. If an application explicitly changes the file modification time, it might only do it with second resolution. And so on.

In the end, I don't think it should affect your backup scheme that much for you to worry about it.

Upvotes: 1

Related Questions