Last modified timestamp not preserved when using pCloud

[storm1ng]

Please agree to the following

• I have searched existing issues for duplicates
• I agree to follow this project's Code of Conduct

Summary

When you copy a file the last modified timestamp is not preserved when the vault is located on a pCloud drive

What software is involved?

• Operating System: Windows 11 21H2
• Cryptomator: 1.6.5
• WinFSP 2022 (1.10.22006)

Volume Type

No response

Steps to Reproduce

1. Create new vault on a pCloud drive
2. Open vault
3. Copy any file into the vault.
4. Compare last modified date of file within the vault with the local one.

Expected Behavior

The last modified date is preserved and the same as the one of the file copied.

Actual Behavior

The last modified date is set to the current date and time.

Reproducibility

Always

Relevant Log Output

No response

Anything else?

I checked the behaviour with OneDrive and couldn't reproduce it there so it seems to be a limitation with pCloud mounted drives.
When I copy the file directly to the pCloud drive (not into the vault) the last modified date is preserved.

[storm1ng]

As @SailReal pointed out, this might be related to #2012

However, it is weird that this issue is not present when using a vault on OneDrive.

[overheadhunter]

However, it is weird that this issue is not present when using a vault on OneDrive.

Indeed. I mean, if pCloud just didn't support setting a last modified date that lies in the past, that would at least make sense. But apparently it works normally when directly interacting via Explorer.

[storm1ng]

Indeed. I mean, if pCloud just didn't support setting a last modified date that lies in the past, that would at least make sense. But apparently it works normally when directly interacting via Explorer.

Yeah, that doesn't make sense at all...

[TheAndyChow]

I'm having the same issue on Google Cloud Storage and Backblaze B2, with both FUSE and Dokany.

Modified date in File Explorer seems fine at first, but all 3 timestamps in the file properties dialog box are set to the copy-time.

Modified date on OneDrive is OK, in both File Explorer and file properties.

Edit: When I list the file in Command Prompt, it shows a special character instead of a date, and it also says "The parameter is incorrect" under the entry.

[fabo123456]

Hi all
Same problem here. It seems to work with change to WebDAV.

[user-4247]

This problem still does not work (i.e., is not fixed) with Cryptomator 1.7.1 and the new WinFSP update.

[aortan]

Same issue here on pCloud Disk Streaming on a Mac....

[LearningAsIGo71]

Have the developers given up on this issue? More than a year and seven months later since this issue was first reported and it still exists when using Cryptomator with pCloud. Latest version of Win 10 Pro, Cryptomator 1.10.1 using WinFsp. Using Windows Explorer, every file I copy from my local drive to my Cryptomator vault in pCloud changes the Created, Modified, and Accessed dates and times to today's date and time. This makes Cryptomator unusable for me.
[Edit for clarity]

[LearningAsIGo71]

Been doing some experimenting and found an usual way to get files from my local drive to my Cryptomator vault with dates and times preserved. As stated above, if I use Windows Explorer to copy and paste files from my local drive to the vault all the files' dates change to today's date, but if I use FreeFileSync for Windows to sync files from my local drive to my vault, all the file dates are preserved! The only dates that are not preserved and change to today's date are folder dates. But I could care less about folder dates; it is the file dates that are important for me. I will continue experimenting with this and see if this anomaly continues and also if it holds true when using another file sync app for Windows called SyncBack.

[LearningAsIGo71]

Strange... I just tried to sync some more files in the manner described above, but this time using SyncBack and the timestamps were not preserved. I then deleted the files from the vault and re-synced the identical files with FreeFileSync and all the file timestamps are once again preserved!

No idea what FreeFileSync is doing to preserve the timestamps, but maybe someone else can try it out to see if they get the same results. FreeFileSync is a free, open-source sync app available at freefilesync dot org

[nixomose]

There is an os call that lets you specify the timestamp of an existing file and I think some of the pcloud tools don't support it. I looked into this a while ago but I forget the details. Are you using the pcloud client to mount the remote drive locally?

…

On Sat, Sep 30, 2023, 12:05 PM LearningAsIGo71 ***@***.***> wrote: Strange... I just tried to sync some more files in the manner described above, but this time using SyncBack and the timestamps were *not* preserved. I then deleted the files from the vault and re-synced the identical files with FreeFileSync and all the file timestamps are once again preserved! No idea what FreeFileSync is doing to preserve the timestamps, but maybe someone else can try it out to see if they get the same results. FreeFileSync is a free, open-source sync app available at freefilesync dot org — Reply to this email directly, view it on GitHub <#2058 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADI2M2SION2IYHT2IOB4IWTX5A7LPANCNFSM5OI5DBGA> . You are receiving this because you commented.Message ID: ***@***.***>

[LearningAsIGo71]

Yes... using the Windows pCloud client to mount the remote drive locally. I then use FreeFileSync to sync my files from my local data drive (D:) to my mapped Cryptomator vault (G:) (which is within my mapped pCloud drive (P:). So far all the filetypes I have transferred (docx, jpg, and mp3) have had their timestamps preserved when transferring them using FreeFileSync.

[TheAndyChow]

Try using Cyberduck and make sure Preferences > Transfers > Uploads > Preserve modification date is enabled. I've tried many combinations of drive mounting software, file upload software, and storage providers. Cyberduck (but not Mountain Duck) is the only method that can consistently preserve timestamps.

[LearningAsIGo71]

Thanks, I'll look into it!

[LearningAsIGo71]

Yes... using the Windows pCloud client to mount the remote drive locally. I then use FreeFileSync to sync my files...

Unfortunately, using FreeFileSync to sync my local files with my mapped Cryptomator vault is not consistent. Some documents now have not preserved their date when getting synced to the Cryptomator vault. This is a real problem. I lost several updates to an important Word doc as a result.

[juvro]

I confirm the issue. Since many versions.
Elements to investigate :

1. Does not occurs with a Google Drive disk, but does occurs with a pCloud Drive.
2. I thinks it occurs only if the vault is in the pCloud disk virtual drive. If you use a pCloud drive/cryptomator vault with a "device folder" syncrhonisation (copy of encrypted files are on your HDD), i think that the issue is not present (file timestamp creation are preserved and not modified with the timestamp of the copy operation).
   If you use the pCloud disk virtual drive (=> without a local copy of encrypted files on your HDD), the issue is present.

[LearningAsIGo71]

I need some clarification as I do not understand point #2. How do I create a Cryptomator vault with a device folder sync?

[juvro]

With the "sync" tab in pcloud

=> I have, on the pCloud virtual drive (P:), a folder that is really stored on my HDD ("c:...\pCloud Drive"). And one drive that has no local copy on HDD

[juvro]

=> Copying files on vault mapped on c:..\pCloud Drive => Timestamp preserved (green arrow)
=> Copying files on vault mapped on p:\pCloud No Local Copy => Issue is present (red arrow)

[LearningAsIGo71]

Thank you for the explanation with pics. So in creating a local Cryptomator vault to sync with pCloud, what type of vault volume is recommended, WinFsp (Local Drive)?

[LearningAsIGo71]

Still waiting on a response before I give this a go. Is there a recommended vault type for using with pCloud sync?

[juvro]

Still waiting on a response before I give this a go. Is there a recommended vault type for using with pCloud sync?

If this question is addressed to me (the author of the last comments), I can't answer it, sorry..

[LearningAsIGo71]

If this question is addressed to me (the author of the last comments), I can't answer it, sorry..

Ah well, thanks anyway... I'll see what I can figure out.

[juvro]

Hello. Any news on this issue ? I hope my "steps to reproduce" above can help.. Thanks.

[infeo]

This might be related to #3301

[infeo]

We released the first beta for the upcoming Cryptoamtor 1.12.3 version.

@juvro @LearningAsIGo71 and others: Can you try the beta and test, if the issue is still present?

[JeffreyRon]

I'm having this date/time stamp issue too. Here are the results of 2 tests I ran.

Test 1
Using: Windows 11 Pro, pCloud Drive software, Cryptomator 1.12.0 (msi-5144)

Copied and pasted a file using File Explorer to:

• pCloud: (Date Created retained original, Date Modified retained original)
• pCloud (Cryptomator) Vault: (Date Created set to current, Date Modified set to current)

Test 2
Using: Windows 10 Home, pCloud Drive software, Cryptomator 1.12.3-beta1 (msi-5191)

Copied and pasted a file using File Explorer to:

• pCloud: (Date Created retained original, Date Modified retained original)
• pCloud (Cryptomator) Vault: (Date Created set to current, Date Modified set to current)

Summary: Same results in both tests. Copying files directly to pCloud will retain the original date/time. Copying files to pCloud with Cryptomator Vault will result in date/time resetting to current time.

I repeated these tests to verify the results. Bottom line is I'm trying to use SyncBack to copy files from my local machines to the cloud for off site backups. When the dates get modified then the sync requires ALL files to be copied again unnecessarily. I hope there is a resolution. Otherwise I will have to come up with a different strategy.

[infeo]

@JeffreyRon thanks for the extensive test. Regarding creationDate, this is not supported by the FUSE volume types (see #1117 (comment)).

[JeffreyRon]

After more testing I found something interesting. I was able to use SyncBack and keep the original file dates when copying to pCloud/Cryptomator drive. You must edit the profile and go to the Copy/Delete tab on the left and the Advanced tab across the top, You must check the option: "Force the modification date & time to be correct". All the folders get new current dates, but I think that is to be expected. But at least the files keep their original date.

[infeo]

I looked a bit at the problem and it revealed a foundational problem. pCloud Drive breaks with a basic assumption, as shown with the following code:

var content = ByteBuffer.wrap("hello world!".getBytes(StandardCharsets.UTF_8)) ;
var p = Path.of("P:\\pcloudTest\\foo.bar");
//1. create file and open channel
try( var ch = FileChannel.open(p, StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE_NEW)) {
	//2. write something to file
	ch.write(content);
	
	//3. flush data
	ch.force(true);
	
	//4. set lastModifiedTime to 1997-05-19T00:00:00Z
	var mTime = FileTime.from(10000, TimeUnit.DAYS);
	BasicFileAttributeView view = Files.getFileAttributeView(p, BasicFileAttributeView.class, LinkOption.NOFOLLOW_LINKS);
	view.setTimes(mTime, null, null);
	
	//5. closing channel
}

//6. read file attributes/lastModifiedTime
var basicAttr = Files.readAttributes(p, BasicFileAttributes.class);
System.out.println("File "+ p +" has mTime of "+ basicAttr.lastModifiedTime());

Expected output: "File P:\pcloudTest\foo.bar has mTime of 1997-05-19T00:00:00Z"
Actual output: "File P:\pcloudTest\foo.bar has mTime of 2024-02-28T11:00:00Z"

Our assumption is, that closing a channel should only change the modification date, if there are actual changes written to storage. By performing step 3, the channel should not contain any changes. Still the lastModifiedTime is overwritten to "now", when the channel is closed.

@overheadhunter we coukld workaround such behaviour by setting the lastModifiedTime after closing the channel in cryptofs. But as i recall, you had objections about this approach.

[juvro]

We released the first beta for the upcoming Cryptoamtor 1.12.3 version.

@juvro @LearningAsIGo71 and others: Can you try the beta and test, if the issue is still present?

I just tesed it with latest version (1.12.3), and I confirm that the issue is still present in that version. Thanks.

[overheadhunter]

@overheadhunter we could workaround such behaviour by setting the lastModifiedTime after closing the channel in cryptofs. But as i recall, you had objections about this approach.

Not objections per se, but I have the vague feeling that the exact order is a very delicate setting that might interfere with expectations of third party apps writing to the VFS. So it requires intensive testing.

[storm1ng]

@overheadhunter
I tested the modified timestamp on my Arch Linux setup using pcloud-drive (AUR) and cryptomator (AUR) (since I wasn't able to get cryptomator-bin to play nicely with FUSE).

For me the modified date was preserved when copying a file to a vault which resides on my pCloud account.
Not sure though how it behaves on Windows. I will check that on my other machine.