Check file changes based on content instead of the last_modified metadata

[skukhtichev]

Problem

JupyterLab mechanism to detect a file changes is based on last_modified parameter set in the metadata:

jupyterlab/packages/docregistry/src/context.ts

Lines 644 to 649 in b4db7f0

	const modified = this.contentsModel?.last_modified;
	const tClient = modified ? new Date(modified) : new Date();
	const tDisk = new Date(model.last_modified);
	if (modified && tDisk.getTime() - tClient.getTime() > 500) {
	// 500 ms
	return this._timeConflict(tClient, model, options);

.
If the file last_modified parameter was changed without changing the content then JupyterLab shows the following message

The issue happens when sync tools are used that updates files last modified timestamp.

Proposed Solution

Using content based check mechanism (e.g. hash) will prevent showing the dialog when the last modified timestamp changed without changing a file content

Additional context

[telamonian]

👍 I like this, definitely worth trying out

There's several different ways you could implement this, and you could do the actual hash in either the frontend or in the backend jupyter_server.

[robinovitch61]

I would be interested in taking a crack at this unless you're particularly gung-ho @skukhtichev

[blink1073]

xref jupyter-server/jupyter_server#409

[vidartf]

xref #9777

[vidartf]

The issue happens when sync tools are used that updates files last modified timestamp.

It seems weird that the sync tool updates the last modified timestamp even if no change is made. Do you know why this happens, and if it is possible to avoid it? If possible, that would be a better fix, rather than building some special case workaround into the frontend.

[jasongrout]

It seems weird that the sync tool updates the last modified timestamp even if no change is made. Do you know why this happens, and if it is possible to avoid it? If possible, that would be a better fix, rather than building some special case workaround into the frontend.

I agree with @vidartf - it seems that the responsibility lies with the one tool that is updating the timestamp to not update it if the content hasn't changed (i.e., to respect the meaning of "last modified"), rather than every other tool having to check if content actually changed.

[fcollonval]

Closing as fixed by #15577