[Bug]: Nextcloud isn't preserving millisecond value on file modified timestamp which causes some apps to get confused

[munrobasher]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

Some applications monitor the modified timestamp on a file to determine if it's been changed whilst you have the file open. For example, Excel remembers the modified time of a file when you open it. On saving, if the modified time has changed, it infers somebody else has changed it and prompts if you want to overwrite. Notepad++ monitors the modified timestamp and if it changes, you're prompted to re-load the file.

The bug is that Nextcloud client (assumed but could be server) isn't preserving the millisecond value on the server and the Nextcloud client zeroes the millisecond value.

This then causes Excel to believe somebody else has changed the file and Notepad++ to prompt to reload even though the file hasn't changed. Get your answer wrong and you can loose edits.

Steps to reproduce

1. Save a text file using Notepad++ to a group folder.
2. Check the milliseconds value on the client using the PowerShell command below.
3. Wait a while or click sync in Nextcloud client.
4. Look at millisecond value again and it's reset to zero.
5. Notepad++ thinks the file has changed (it hasn't) and prompts to re-load

If you happened to have made edits between steps #1 and #5, they will be lost if you reload.

PowerShell: (Get-ItemProperty $Path).LastWriteTime.Milliseconds

This video demonstrates the issue: Video of issue

Expected behavior

The millisecond value in the modified time should be preserved, written to server and not zeroed by the client.

Which files are affected by this bug

All files but most problematic with Excel files

Operating system

Windows

Which version of the operating system you are running.

Windows 10, Windows 11

Package

Appimage

Nextcloud Server version

27.1.3

Nextcloud Desktop Client version

3.10.1 using virtual files

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Too large to upload here. Can be downloaded here:

https://maltsystems-my.sharepoint.com/:u:/g/personal/rob_nicholson_maltsystems_co_uk/EbxRPMGNp5tNstw38eKIOpUBwSV77crWyvc9esg598hYcA?e=zOptIZ

Additional info

I've looked at the timestamp on the Nextcloud CentOS v7 server using ls -l --full-time and the milliseconds value when first uploaded to Nextcloud is zero. So not surprised this issue is occurring. The Linux server can handle milliseconds in modified times so it's not a problem on Linux as such. Whether it's the client or server is difficult for me to say.

[munrobasher]

I have a test Nextcloud system running on a virtual machine in my lab. Just tried to repeat in this environment and same problem. Not using a group folder this time but a text document stored in my Documents folder.

LATER - the issue doesn't occur when you download all files, i.e. it's only an issue with virtual files.

[mgallien]

I posted a test build in the linked PR, people could you please test it and report your results here ?
that would be greatly appreciated and useful

[pym67]

one my side I'm still reproducing the original issue on the test build

[munrobasher]

I'll try the test build ASAP.

[munrobasher]

Please to report that this problem appears to be fixed in the linked pull request version. I've updated my test script to be a bit more useful. It monitors the file and only updates the display when the file is changed. The millisecond value remains as first saved and doesn't get set to zero. This means that Notepad++ doesn't prompt to re-load it. Result - with caveat.

I tried with Excel and initially I thought it was fixed as milliseconds remained for quite a while, but then zeroed. However, I think I can explain this. I was using an Excel document that will have been downloaded locally on other computers. I suspect until all clients are updated, the following scenario occurs:

BEGIN
Computer A with fixed client re-saves existing file - milliseconds non-zero
Computer B with old client spots the timestamp change, re-synchronises it and zeroes milliseconds
Computer A then also zeros as it's changed
END

Param([String]$Path)
While ($True) {
	$LastWriteTime = (Get-ItemProperty $Path).LastWriteTime
	$LastMillisecond = $LastWriteTime.Millisecond
	If (($LastWriteTime -ne $CurrentWriteTime) -Or ($LastMillisecond -ne $CurrentMillisecond)) {
		Write-Host $LastWriteTime $LastWriteTime.Millisecond
		$CurrentWriteTime = $LastWriteTime
		$CurrentMillisecond = $LastMillisecond
	}
	Start-Sleep -Millisecond 500
}

[munrobasher]

Interesting side note - PowerShell ignores milliseconds when comparing timestamps. In the above script, I originally didn't have the test for milliseconds in the if statement and it looked like the bug didn't occur. However, when I also added the millisecond comparison it did. One gets the feeling that this millisecond issue is one of those can of worms things. Bit like MAXPATH in Windows :-)

[pym67]

"I tried with Excel and initially I thought it was fixed as milliseconds remained for quite a while, but then zeroed. However, I think I can explain this. I was using an Excel document that will have been downloaded locally on other computers. I suspect until all clients are updated, the following scenario occurs:"

In my test lab, i've updated only one computer with the window test version and on the Linux backend, i still see milliseconds to be zeroed on files modified by this computer.

[munrobasher]

This has been closed but the fault is still occurring with client 3.11.1:

[roberix]

Hi.

I can definitely report it fixed in 3.10.4.

Weird.

Regards

rob

[pym67]

I experience the same issue as munrobasher, issue still reproduced daily on updated version of both server & client

[munrobasher]

Something has changed though. Previously when one saved an Excel document, the millisecond value was non-zero for a while and then reset to zero without doing anything (or rather waiting for the client to resync). However, I'm just running this PowerShell script:

Param([String]$Path)
While ($True) {
	$LastWriteTime = (Get-ItemProperty $Path).LastWriteTime
	$LastMillisecond = $LastWriteTime.Millisecond
	If (($LastWriteTime -ne $CurrentWriteTime) -Or ($LastMillisecond -ne $CurrentMillisecond)) {
		Write-Host $LastWriteTime $LastMillisecond
		$CurrentWriteTime = $LastWriteTime
		$CurrentMillisecond = $LastMillisecond
	}
	Start-Sleep -Millisecond 500
}

It monitors a file and if the millisecond changes, it reports the change. I've saved the file and it's staying with a millisecond value. However, if I close and re-open the file, it resets milliseconds to zero. So this is new - re-opening a file resets the milliseconds to zero which it should not do.

[roberix]

Hi.

That obviously would trigger an unwanted snyc I guess. I can confirm that I see that as well.

Regards

rob

[munrobasher]

Repeated several times with Excel. Now the simple fact of opening an Excel document zeros the milliseconds value. But this issue doesn't happen with Notepad++ which before used to report that it thought the file had changed when the milliseconds was reset by the client. Re-opening the same document in Notepad++ and the timestamp/milliseconds value is preserved.

I haven't a clue why Excel would behave differently... just about to try with Word.

Later... yes, same issue with Word. And LibreOffice Draw...

[roberix]

Hi.

@munrobasher which Excel do you use?

Regards

rob

[munrobasher]

Microsoft 365 current channel currently version 2401 Build 16.0.17231.20194 64-bit.

[munrobasher]

v3.12.0 has just been released and this contains the fix:

avoid modifying a placeholder (virtual files) when not needed by @mgallien in #6212

So will install and report back.

[roberix]

Hi.

The fix was also in 3.11 so supposedly working in your version.

I am interested in your findings with 3.12

regards.

Rob

[munrobasher]

It's better but there is still a quirk on opening Excel documents - opening clears milliseconds. Need to find some time to dig deeper.

[Mika-6-9]

Hi.
It's the same with 3.12 and Nextcloud server 27.1.1 and Nextcloud files_lock 27.0.4

[Mika-6-9]

@munrobasher or admin could you reopen this issue as it is not resolved

[willemb2]

IMHO this is NOT resolved. I'm seeing this issue 9 out 10 times when saving an Excel file using client 3.12.3. I think it started with 3.10.0, but not 100% sure. Not using Group Folders. I cannot reproduce it with Notepad++. The Powershell command from the OP never returns a milliseconds value here. Could be my lack of experience with PowerShell.

Edit: I managed to get the milliseconds using this command:
wmic DataFile where "Name='C:\\Path\\to\\documents\\test.xlsx'" get LastModified /VALUE
(note: double backslashes)

Done some more testing:

1. I’m not getting this issue on my spare Windows 10 laptop (22H2 build 19045.4291)
2. On my Windows 11 system (23H2 build 22631.3447), with the Nextcloud client running the milliseconds part of LastModified is reset zero as soon as I open the following file types:

• .xlsx (Excel)
• .docx (Word)
• .odt (LibreOffice)

3. Currently only Excel prompts if I want to overwrite but I have seen it happen in Word as well until a few weeks ago.
4. It does not happen with .txt or .pdf (PDF Exchange Pro)
5. The zeroing only happens when the Nextcloud client is running
6. The zeroing does not happen on the Windows 10 machine where the issue is absent.

[Mika-6-9]

Hi
For us it's a bug with win10 and win11

[CDubs00]

Im using macOS Virtual files, and editing .md file with textedit.app and having this issue.

Nextcloud desktop client 3.13.3
Nextcloud server 29.0.6