Cut the Clutter: Test Ignore Files Feature - sign up to become a beta tester here.
Forum Discussion
What is the official timestamp behaviour of Dropbox files?
I have seen previous posts on this issue, with some of the described behaviour not mimicking what I see in practice, so I'm wondering what the intended behaviour is.
When I copy/drag and drop a file to dropbox, the LastModifiedTime is preserved (and not updated to the time it was copied). The same file in other instances of Dropbox running on other machines shows the same LMT. This is what I expect. Several of my build chain tools rely on this behaviour.
If I rewrite the Dropbox file in situ (i.e. CreateFile) the LMT is updated to the current time. The new LMT propagates through to other instances of Dropbox within a second or so. Again, all good.
If I touch the Dropbox file (i.e. use a touch utility, which only updates the LMT) the LMT is updated to the current time on the local file, but the new LMT doesn't propagate through to other instances of Dropbox. Sort of inconsistent really.
The reason I'm curious is that I am using small files as flags to communicate between PCs. When a remote PC sees the LMT on a file change, they know to go and do something. I was thinking that using the Touch utility to set the LMT instead of rewriting the file each time would result in less churn between the PCs and Dropbox servers, as the file wouldn't be in a state of continuous "blue dot overlay on the Dropbox tray icon" syncing. (I have just had a thought while writing this that maybe writing a zero-length file each time would have the same effect - currently I rewrite a file with a line of text containing the current date but I don't really need to. I will try that and report back).
Anyway I thought I remembered seeing a historical post suggesting that we can't place too much reliance on the LMT of the file. What is the official line on this? :
- The LMT of a Dropbox file will always propagate through to other Dropbox instances.
- The LMT of a Dropbox file will always propagate through to other Dropbox instances, but only if the file is rewritten, and not just "touched".
- The LMT of a Dropbox file's behaviour is undefined and shouldn't be relied upon.
- none of the above (please specify 😁)
I don't really care what the CreateFileTime does, but the same questions probably apply and might be relevant to other users.
1 Reply
Replies have been turned off for this discussion
- Rich
Super User II
rossmcm wrote:
If I touch the Dropbox file (i.e. use a touch utility, which only updates the LMT) the LMT is updated to the current time on the local file, but the new LMT doesn't propagate through to other instances of Dropbox.
That's working as expected. Dropbox doesn't use timestamps to sync files. It looks at the content of the file to determine if it needs to sync. Changing just a timestamp doesn't update the file's content, so Dropbox won't sync that change. You have to write data to the file in order for Dropbox to recognize it as a changed file.
