Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Theme Files are removed from Source Folder when (re)exporting using Fast Save #521

Open
nickjohnsonpond opened this issue Jul 10, 2024 · 3 comments

Comments

@nickjohnsonpond
Copy link

nickjohnsonpond commented Jul 10, 2024

Windows 11 Pro 10.0.22631 Build 22631
MS Access for MS 365 V 2406 Build 16.0.17726.20078 64 bit
vcs-addin 4.0.34

I've been experiencing glitchy behaviour with my database colours and fonts changing after a build and so have been using the tried and true 'push all the buttons to see if anything fixes the problem' technique.

I can consistently replicate the issue when I have Options:

Use Fast Save - True
Extract Theme Files - True
Sanitize Colors - None (Off)

Using the Export Source Files button from the Ribbon
First time running the Export it takes about 4-5 seconds, I note that the displayed log form states
Exporting Themes [1]

Second export takes about 0.48 seconds and the displayed log suggests that nothing has changed, however the entire \themes folder and contents is removed from the source folder.

Interestingly the Export.log file for the Fastsave states

No modified themes found in this database.

and the operations table doesn't seem to indicate any deletions (except possibly the "Clear Orphaned Files" row.)

--------------------------------------------------
Operations                    Count     Seconds
--------------------------------------------------
Clear Orphaned Files          15        0.11
Convert to JSON               853       0.10
Scan DB Objects               1         0.08
Increment Progress            205       0.04
Check for linked table        58        0.03
Console Updates               2         0.03
Parse JSON                    1         0.01
Get VBA Hash                  58        0.01
Parse JSON ISO Date           133       0.00
Compute SHA256                71        0.00
Quick Count Files             1         0.00
Quick Count Objects           1         0.00
Read File                     1         0.00
--------------------------------------------------
Other Operations                        0.02
--------------------------------------------------

If I turn on the option Show Detailed Output or turn off Use Fast Save this deletion doesn't occur.

@nickjohnsonpond
Copy link
Author

I've done a bit of digging and I think I can see what's going on here.

Firstly I was misunderstanding what is happening.

It appears that the entire themes folder is deleted on every export run when ClearOrphanedSourceFiles is run on the "Office Themes" category in modImportExport.ExportSource. This happens regardless of whether Fast Save is used or not because on a successful run of a themes export, the .thmx file is removed from the theme folder after being extracted. This means there are no files in the theme folder, only a subfolder. ClearOrphanedSourceFiles expects a flat folder structure like the other source folders and so the lack of files (at least in my case) triggers deletion of the whole themes folder (and all it's extracted subfolders).

On a Full Export the folder is then immediately re-created along with the extracted files and subfolders.

On a Fast Save export run, if the theme hasn't changed relative to the VCSIndex then no file is exported (or extracted) and the folder stays deleted.

I can see two issues here but admit I'm not really clear on a what would be a good design solution.

  1. ClearOrphanedSourceFiles doesn't check for subfolders before removing the folder
  2. The VCSIndex isn't 'aware' of subfolders, it only keeps a reference to the original .thmx file

Since the subfolders/files aren't indexed, then even if ClearOrphanedSourceFiles looked for them, they would presumably be flagged as orphaned and deleted anyway.

I haven't dug through the conflict handling code, but I assume it's based on the same index so if a developer modified the theme files directly, or another developer modified the theme, then a subsequent export would quietly overwrite those changes.

@nickjohnsonpond
Copy link
Author

Ah. I've misunderstood the intent of the Extract Theme Files option. I originally interpreted that as meaning "Extract Theme Files to the file system from the database" but now realise it's "Extract Theme Files and folders from the .thmx file". Heh.

The issues described above still remain with the extracted files, but I've realised if I don't use the extracted files option I can use either "Fast Save" or "Full Export" and it doesn't trounce the "themes" folder each time. Change control is going to be pretty monolithic on a single thmx file, but it serves my immediate purposes.

I still like the idea of being able to do finer change control on the extracted theme files but would need to understand the existing code a lot better than I currently do to work out a sane approach.

I feel like one way or another the extracted files would need to be incorporated into the VCSIndex, but I'm not sure whether it'd be more or less pain to adapt the existing clsDbTheme class to handle the extra filesystem, acrobatics, or make a new class like clsDbThemeComponent.

Interested if anyone can offer any pointers or insights.

@hecon5
Copy link
Contributor

hecon5 commented Jul 12, 2024

I experienced similar things.

We do not change themes often (ever, honestly). Really, once you pick a theme it won't change much ever again unless your office rebrands. We decided having everything in a single file did not deter from our version tracking as it never changed anyway once we set it up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants