Item15292: WebRename updates the mtimes of all ,pfv/ files, thus breaking the history

Renaming a web changes the timestamp of all files in the *,pfv/ folders to the current date. Thus, when viewing the history of a topic, all of the topic's versions are shown as having all the same date. The topic files themselves (the *.txt files) are not being touched (unless the web's rename affects links in a particular topic), only the ones in the *,pfv/ folders.

It is possible to restore that information by reading the %META:TOPICINFO line of each file and set the mtime accordingly, but the rename of a web should not change the history files's timestamps at all in the first place.

-- ChristianKern - 31 Jan 2024

This is a design flaw in the PlainFile Store. From to the documentation

'date' always comes from the file modification date

This was a intentional decision of Crawford who implemented the store back then. This is one of the areas where it clearly differs from other store implementations.

-- MichaelDaum - 31 Jan 2024

The date shown in the history comes from the file's modification date: Yes, I knew that. The bug here is that the modification date of old versions is being changed.

-- ChristianKern - 31 Jan 2024

Understood. I totally agree with this being called a bug.

As part of the files being moved around during web rename, their modification date changes too. The PlainFileStore thinks that those files might have changed. They didn't. That's the false assumption in the implementation.

The idea of taking the modification time directly from the file tries to cover those cases where topic files are changed by a script or otherwise without using the Foswiki store api itself. Internally, the PlainFileStore tries to "save damage" when it detects out of band changes and then automatically create interim revision entries assigned to the "unkown user".

The problem here is that renaming a web does not damage the topics even though their file modification time is out of sync with previous revision information. Thats a fundametal false assumption in PlainFileStore.

Looking at the implementation, there is no easy fix as far as I can see.

-- MichaelDaum - 31 Jan 2024

I could provide a Python 3 script that fixes the mtimes by reading the %META:TOPICFILE lines. Would that help? Or is it required that all code must be Perl?

-- ChristianKern - 31 Jan 2024

Any help is welcome. Programming languages don't matter. However if there was a fix to the store impl itself, that would be great.

-- MichaelDaum - 31 Jan 2024

Well, I never was a great Perl programmer and I haven't coded any Perl for more than fifteen years. So I think fixing the code by myself is not a option. I'll rework my Python script and send it to your e-mail address this week.

-- ChristianKern - 31 Jan 2024

Please don't email it, upload it to this topic, please. Thanks in advance.

-- MichaelDaum - 31 Jan 2024

I've uploaded the script yesterday.

• repair_pfv_file_timestamps: Proposal for a Python 3 script repairing the ,pfv folder file timestamps

-- ChristianKern - 01 Feb 2024

Thanks!

-- MichaelDaum - 01 Feb 2024

Commenting is disabled while not logged in