How could I copy (sync) the time stamps (without synchronizing the files) of the files from e.g. the local files to the files on the server?
After a compare I tried to set the direction of equal files to the right (or left) but the direction did not change? How could I make it work?
Copy / sync time stamps?
- Posts: 6
- Joined: 21 May 2017
- Posts: 6
- Joined: 22 May 2017
Coincidentally I also asked the same question just yesterday? Did you find any solution? If so, please do reply. Thanks a lot.
- Posts: 6
- Joined: 21 May 2017
No, I didn't find one, sorry
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
This doesn't seem to be a safe operation, unless it's somehow proven that the files are binary identical.
- Posts: 6
- Joined: 21 May 2017
I tried to do it after a compare by ccontent.
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Time-wise you might as well have compared via time and size and run a normal sync.I tried to do it after a compare by ccontent. Boyzy, 24 May 2017, 06:54
- Posts: 6
- Joined: 21 May 2017
Sorry, I do not understand the meaning of that in this context.
Is it referring to this:
After a compare by content I tried to set the direction of equal files to the right (or left) but the direction did not change?
Or / and this:
How could I copy (sync) the time stamps (without synchronizing the files) of the files from e.g. the local files to the files on the server?
Is it referring to this:
After a compare by content I tried to set the direction of equal files to the right (or left) but the direction did not change?
Or / and this:
How could I copy (sync) the time stamps (without synchronizing the files) of the files from e.g. the local files to the files on the server?
-
- Posts: 2451
- Joined: 22 Aug 2012
@Boyzy
It seems you don't get the point.
Like stated in Zenju's earlier reaction, copying/syncing the time stamps only makes sense if you are sure the file content is identical (in Zenju's terms: binary identical).
Like you stated, you first run a compare by content and verify if the file content is identical.
However, comparing file content means that the file content of both file-locations needs to be brought to the computer running the FFS comparison/sync. One of the two might be local to that machine, but the other locations file content needs to traverse over the network.
This involves the same amount of network traffic as when simply copying the files over, and thus running a comparison on time&size, and copying over the files that have a discrepancy in time&size is just as fast as running a comparison on file content.
The step two steps required in your setup (step 1: comparing on content; step 2: copying files of different content and just copying the timestamp if the content was identical) takes at least as much time/traffic as running a "normal" compare on time&size and consequent sync.
However, getting back to your initial question: FFS (presently) does not have the capability to copy just the time-stamp of files and likely neither will have that in the future.
It seems you don't get the point.
Like stated in Zenju's earlier reaction, copying/syncing the time stamps only makes sense if you are sure the file content is identical (in Zenju's terms: binary identical).
Like you stated, you first run a compare by content and verify if the file content is identical.
However, comparing file content means that the file content of both file-locations needs to be brought to the computer running the FFS comparison/sync. One of the two might be local to that machine, but the other locations file content needs to traverse over the network.
This involves the same amount of network traffic as when simply copying the files over, and thus running a comparison on time&size, and copying over the files that have a discrepancy in time&size is just as fast as running a comparison on file content.
The step two steps required in your setup (step 1: comparing on content; step 2: copying files of different content and just copying the timestamp if the content was identical) takes at least as much time/traffic as running a "normal" compare on time&size and consequent sync.
However, getting back to your initial question: FFS (presently) does not have the capability to copy just the time-stamp of files and likely neither will have that in the future.
- Posts: 6
- Joined: 21 May 2017
Well, well, actually I would not say so, I would say there might be other reasons as well.Like stated in Zenju's earlier reaction, copying/syncing the time stamps only makes sense if you are sure the file content is identical (in Zenju's terms: binary identical).
Very sorry, I cannot find any sense. How can one know that the "files that have a discrepancy in time&size" are equal by content (if not compared by content)? And / or why are the "files that have a discrepancy in time&size" the same ones being equal by content? Sorry again for my bad understanding.Like you stated, you first run a compare by content and verify if the file content is identical.
However, comparing file content means that the file content of both file-locations needs to be brought to the computer running the FFS comparison/sync. One of the two might be local to that machine, but the other locations file content needs to traverse over the network.
This involves the same amount of network traffic as when simply copying the files over, and thus running a comparison on time&size, and copying over the files that have a discrepancy in time&size is just as fast as running a comparison on file content.
Sorry again, I absolutely do not understand. By the way, the traffic doen't matter at all to me. Before I can do step 2 I have to do another step, find out the direction (to my computer or to the server) I have to copy the files to, so I would have to (again) compare the content (e.g. text) with another program (causing more traffic / needing more time) and may be another step to correct / edit one of the unequal files.The step two steps required in your setup (step 1: comparing on content; step 2: copying files of different content and just copying the timestamp if the content was identical) takes at least as much time/traffic as running a "normal" compare on time&size and consequent sync.
Alright, that's a pity.However, getting back to your initial question: FFS (presently) does not have the capability to copy just the time-stamp of files and likely neither will have that in the future.
And how could one do this:
After a compare by content I tried to set the direction of equal files to the right (or left) but the direction did not change.
- Posts: 6
- Joined: 22 May 2017
After going through this thread, my question is that:
How to tell (udate the DB?) FFS to mark both sides as equal without copying/updating the files?
My situation is that, I have copied some five thousands files to a MTP device. The time stamps are now different, but I know that files are same. From this point onwards, how do I use FFS and ensure that the first time sync is successful without copying all the files again.
How to tell (udate the DB?) FFS to mark both sides as equal without copying/updating the files?
My situation is that, I have copied some five thousands files to a MTP device. The time stamps are now different, but I know that files are same. From this point onwards, how do I use FFS and ensure that the first time sync is successful without copying all the files again.
