So I created a VeraCrypt container file on a certain date. On a later date, I mount the file, make changes inside of it, then dismount it. The "Date Modified" of the file still stays the same as the date it was created. I'm wondering if this would cause a problem if syncing the file to a cloud service like One Drive or Google Drive? If the file's "Date Modified" never changes, will these cloud services know to re-sync the file?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The file container will not synchronize to the cloud.
You want to synchronize to the cloud by the changing of the modification timestamp on the file container and only synchronize when the file container is closed/dismounted. Otherwise, the file container will be corrupted on the cloud.
Be aware that each time you dismount the file container, the entire size of the file container has to synchronize to the cloud.
To allow the file containers to allow updating the modification timestamp after you dismount the file container, you will need to disable the preserve timestamp in the preferences in settings.
Settings -> Preferences -> uncheck the box "Preserve modification timestamp of file containers".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
...only synchronize when the file container is closed/dismounted. Otherwise, the file container will be corrupted on the cloud.
We don't always know exactly when Google Drive will start syncing. So if you have a VeraCrypt file mounted, and then Google Drive decides that it wants to start syncing the file at this very moment, then will the file be corrupted in the cloud? How do we prevent this from happening?
I have 2 ideas:
1) Leave the "Preserve modification timestamp of file containers" checked and then simply manually upload the dismounted VeraCrypt file every time you make a change to it. Google Drive allows you to manually upload the latest version of any file.
2) Uncheck "Preserve modification timestamp of file containers" and then simply pause syncing every time you mount a VeraCrypt file. After you dismount the file, then you can resume syncing.
Does anyone have any thoughts on any of those ideas? Is there a better way?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mount and dismount without changes. Does the dismount change the timestamp?
Yes, simply mounting and dismounting does change the timestamp.
Mount and change the Notepad file but leave the volume mounted. Does this change the timestamp?
No, the timestamp doesn't change until AFTER I dismount which I guess is a good thing.
So now I'm assuming that as you are making changes to a mounted VeraCrypt file, then Google Drive will not try to sync it since the timestamp will remain the same. It is only until after you dismount the file that Google Drive will try to sync it (and hence the file won't be corrupted). Is this a safe assumption or does anyone have a different experience?
Last edit: John Campbell 2024-08-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did perform the three tests that you recommended which were very informative and thank-you for that. The bottom line is that the timestamp does not seem to change until AFTER the file is dismounted which is a good thing since Google Drive won't try syncing it until after you are finished doing whatever you are doing with it and then dismounting it. So all seems well with syncing a VeraCrypt file to the cloud (at least with Google Drive). I'm just hoping that I don't have a false sense of security.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for running the three tests and providing the VeraCrypt community with your results.
On occasion, determine how you can copy/restore the Google Drive file container to a different location on your PC while leaving your original file container untouched by the copy/restore.
Then on your PC, attempt to mount the Google Drive's copy/restore file container and see if you are able to access your files.
In addition to occasionally testing your Google Drive restore, you can search the VeraCrypt forum for user postings that use Google Drive to get insight to any issues by using the search term with quotes "Google Drive".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just tested it today and downloaded the VeraCrypt file from Google Drive to a different location on my computer. It mounted just fine and I was able to access the files.
For people planning to sync their VeraCrypt files to Google Drive, there may be one thing to be careful about. Say you mount a VeraCrypt file, do whatever you want with it, and then dismount it. The timestamp will change and then Google Drive will either start syncing it or queue it to sync. But what if you need to mount the file again and go back into it for whatever reason? Some people might forget that the file is syncing and mounting it during syncing could corrupt the file. So a safe rule of thumb would be to make sure that the file isn't syncing before mounting it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I created a VeraCrypt container file on a certain date. On a later date, I mount the file, make changes inside of it, then dismount it. The "Date Modified" of the file still stays the same as the date it was created. I'm wondering if this would cause a problem if syncing the file to a cloud service like One Drive or Google Drive? If the file's "Date Modified" never changes, will these cloud services know to re-sync the file?
The file container will not synchronize to the cloud.
You want to synchronize to the cloud by the changing of the modification timestamp on the file container and only synchronize when the file container is closed/dismounted. Otherwise, the file container will be corrupted on the cloud.
Be aware that each time you dismount the file container, the entire size of the file container has to synchronize to the cloud.
To allow the file containers to allow updating the modification timestamp after you dismount the file container, you will need to disable the preserve timestamp in the preferences in settings.
Settings -> Preferences -> uncheck the box "Preserve modification timestamp of file containers".
We don't always know exactly when Google Drive will start syncing. So if you have a VeraCrypt file mounted, and then Google Drive decides that it wants to start syncing the file at this very moment, then will the file be corrupted in the cloud? How do we prevent this from happening?
I have 2 ideas:
1) Leave the "Preserve modification timestamp of file containers" checked and then simply manually upload the dismounted VeraCrypt file every time you make a change to it. Google Drive allows you to manually upload the latest version of any file.
2) Uncheck "Preserve modification timestamp of file containers" and then simply pause syncing every time you mount a VeraCrypt file. After you dismount the file, then you can resume syncing.
Does anyone have any thoughts on any of those ideas? Is there a better way?
Does the timestamp only change once you dismount the file container regardless of file changes in the file container?
PS:
Perform the Settings -> Preferences -> uncheck the box "Preserve modification timestamp of file containers".
Create a small test file container and use a simple Notepad file to change within the mounted file container.
Use Windows Explorer and the refresh (F5 button) to monitor what happens to the file container's timestamp when you:
Yes, simply mounting and dismounting does change the timestamp.
No, the timestamp doesn't change until AFTER I dismount which I guess is a good thing.
So now I'm assuming that as you are making changes to a mounted VeraCrypt file, then Google Drive will not try to sync it since the timestamp will remain the same. It is only until after you dismount the file that Google Drive will try to sync it (and hence the file won't be corrupted). Is this a safe assumption or does anyone have a different experience?
Last edit: John Campbell 2024-08-28
Hi John,
I would perform the three tests in my previous post to determine the results of each test of when the file container's timestamp is modified.
I did perform the three tests that you recommended which were very informative and thank-you for that. The bottom line is that the timestamp does not seem to change until AFTER the file is dismounted which is a good thing since Google Drive won't try syncing it until after you are finished doing whatever you are doing with it and then dismounting it. So all seems well with syncing a VeraCrypt file to the cloud (at least with Google Drive). I'm just hoping that I don't have a false sense of security.
Hi John,
Thank you for running the three tests and providing the VeraCrypt community with your results.
On occasion, determine how you can copy/restore the Google Drive file container to a different location on your PC while leaving your original file container untouched by the copy/restore.
Then on your PC, attempt to mount the Google Drive's copy/restore file container and see if you are able to access your files.
In addition to occasionally testing your Google Drive restore, you can search the VeraCrypt forum for user postings that use Google Drive to get insight to any issues by using the search term with quotes "Google Drive".
I just tested it today and downloaded the VeraCrypt file from Google Drive to a different location on my computer. It mounted just fine and I was able to access the files.
For people planning to sync their VeraCrypt files to Google Drive, there may be one thing to be careful about. Say you mount a VeraCrypt file, do whatever you want with it, and then dismount it. The timestamp will change and then Google Drive will either start syncing it or queue it to sync. But what if you need to mount the file again and go back into it for whatever reason? Some people might forget that the file is syncing and mounting it during syncing could corrupt the file. So a safe rule of thumb would be to make sure that the file isn't syncing before mounting it.