Request fix: File system time stamp interfering with Git LFS/versioning control

When starting a project, if there is a backup project in the folder that is “newer”, Nuendo will ask if you want to open that project instead.

This causes problems with Git/Git LFS. This morning I pulled a project from a Git repo that I pushed yesterday from another machine. Nuendo asked me if I wanted to use the backup project, even though that project is in fact older.

Nuendo seem to use only the file system timestamp, so if the .bak file is pulled before the .npr-file, Nuendo will interpret it as the backup file is newer. Which it always will, since the .npr extention always will cause Nuendo to download it after the .bak according to alphabetical order.

Using the file system time stamp to determine if a file is newer is a blunt and error prone method. With increasing usage of cloud storage, sync between multiple machines and usage within game development, something else needs to be implemented to interpret the age of the backup/project file.

There is no other time information available.
But the timestamp of the file system contains two different times.
Time of origin and time of last change.

This is a known problem with cloud storage.
Some of them have options to leave the timestamps unaltered after synchronization.
The original timestamps will be used instead.

But this is the method that works in most scenarios.
Local and cloud based and independent of the OS.

…but apparently not with Git that is the most wide spread versioning system out there. Especially now with LFS, dealing with binary files is much easier (and cheaper) than using Perforce or other versioning systems.

What if it would save the time stamp from the saved system internally in the file instead of relying on the actual file system time stamp of the system? Don’t know what possible consequences that would result in though.

The time stamp is saved in the files’ header.
It’s independent of the file system or the operating system. Good for portability.

A quick google search reveals, you are not the first person who is dealing with this issue.

If you push binary files (Nuendo project file and the backup file are like binary files for git, I believe) they always get new time stamps.
If Nuendo took the git time (the time saved in the git database) into account, the backup system would fail on systems without git.
And we need to maintain a git repository for every local installation as well.
Or it needs two redundant solutions.

But maybe there are possible solutions on the git side.

Interesting, I was unaware that it was stored in the header.

Git LFS works in a slightly different way though. It replaces the binary files with a placeholder pointing to a binary stored on a separate server (if I’ve understood correctly). This is to prevent having multiple versions locally, creating extremely large repos. You only check out the file from the actual commit you’re working on.

I don’t know if this influences Nuendo, or if Git gives it an extra (new) time stamp when replacing the placeholder. I’ll have a look to see if this is possible to circumvent. Thanks for the input.