View Issue Details

IDProjectCategoryView StatusLast Update
0001639OpenMPTGeneralpublic2022-11-21 22:30
Reporterc0d3h4x0r Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx64OSWindowsOS Version10
Product VersionOpenMPT 1.30.08.00 / libopenmpt 0.6.6 (current stable) 
Summary0001639: Autosave [filename] erroneously includes file extension
Description

In the autosave settings, the claim is that

[filename].AutoSave.[timestamp].[extension]

should yield

mySong.AutoSave.20050327.2343.it

but in reality, my autosave filenames look more like

mySong.mptm.AutoSave.20050327.2343.it

So it appears that [filename] is erroneously including the extension.

TagsNo tags attached.
Has the bug occurred in previous versions?yes
Tested code revision (in case you know it)

Activities

c0d3h4x0r

c0d3h4x0r

2022-11-21 22:11

reporter   ~0005380

Also -- is the filename template supposed to be user-editable?

Saga Musix

Saga Musix

2022-11-21 22:12

administrator   ~0005381

I'd rather say it's maybe a communication issue of the template display than an implementation issue. Due to how autosave versioning management works, the full filename needs to come first, as the cleanup code essentially just iterates over all filename.Autosave.* files. If filename didn't contain the extension, it would iterate over autosaves from both filename.xm and filename.it. And the extension at the end is just to keep the file easily open-able through Windows file associations.

I'd rather change the example filename shown in the UI than changing the cleanup logic.

Saga Musix

Saga Musix

2022-11-21 22:15

administrator   ~0005382

Also -- is the filename template supposed to be user-editable?

It probably maybe was the intention some 16-17 years ago to allow for that, but no, the template is fixed and never was editable.

c0d3h4x0r

c0d3h4x0r

2022-11-21 22:18

reporter   ~0005383

Slight correction -- I believe it's manually-initiated backup, rather than periodic autosaves, where I'm seeing this issue.

Saga Musix

Saga Musix

2022-11-21 22:20

administrator   ~0005384

If you refer to the "create backup copy when saving module", that always creates a backup by replacing the module file extension with .bak. The autosave template does not affect that option. Note that also due to how MFC works, no file extension is included in the autosave filename pattern when autosaving a yet-unsaved file.

c0d3h4x0r

c0d3h4x0r

2022-11-21 22:20

reporter   ~0005385

Nope, I guess manually-initiated backups only ever swap the extension out for .bak -- which I guess wouldn't work so well for your filename.xm versus filename.it example scenario :)

Saga Musix

Saga Musix

2022-11-21 22:21

administrator   ~0005386

which I guess wouldn't work so well for your filename.xm versus filename.it example scenario :)

There is no automatic housekeeping of .bak files.

c0d3h4x0r

c0d3h4x0r

2022-11-21 22:25

reporter   ~0005387

True, but one file's backup could overwrite the other file's backup, which might be bad. :shrug:

Saga Musix

Saga Musix

2022-11-21 22:30

administrator   ~0005388

Well, it's important to keep in mind that the features work quite differently: .bak files are mostly intended for being able to rescue the exact previous version that you maybe accidentally just overwrote, or OpenMPT crashed while writing the file, or whatever - i.e. generally there is a need to access this file immediately, and it's unlikely that you will have edited another file with the same name in the meantime. The file is also always guaranteed to be placed next to the original file, so filename.xm and filename.it would have had to be stored in the same folder to begin with.

Autosaves, however, accumulate over a longer period of time, and depending on settings will all be saved in one central folder. Because of that, being able to tell the source files apart is a bit more relevant. But in the end, extending the backup mechanism to always just append .bak instead of replacing the file extension could make sense though. that would be the best of both worlds.

Issue History

Date Modified Username Field Change
2022-11-21 22:07 c0d3h4x0r New Issue
2022-11-21 22:11 c0d3h4x0r Note Added: 0005380
2022-11-21 22:12 Saga Musix Note Added: 0005381
2022-11-21 22:15 Saga Musix Note Added: 0005382
2022-11-21 22:18 c0d3h4x0r Note Added: 0005383
2022-11-21 22:20 Saga Musix Note Added: 0005384
2022-11-21 22:20 c0d3h4x0r Note Added: 0005385
2022-11-21 22:21 Saga Musix Note Added: 0005386
2022-11-21 22:25 c0d3h4x0r Note Added: 0005387
2022-11-21 22:30 Saga Musix Note Added: 0005388