Deleting Temp Files - Should You or Shouldn't You?

ProffieOS
1

Following on from another thread in which the topic of save files came up, I thought it would be worth having a definitive thread on the subject, as there are clearly gaps in my knowledge, and, I dare say, a few other people’s too.

My own experience of temp files is that for the most part, deleting them in between uploads doesn’t seem to happen automatically but is worth doing.

My understanding is that if you make changes to certain parameters in your config, that you run the risk of introducing inconsistencies and incompatibilities between the uploaded config and the save files, which can then cause problems. As such I’ve always deleted all save files between uploads. This is one of the reasons I built a simple button press into my prop file that deletes them and reboots the saber without you needing to remove the SD card. This also serves as a “Restore Config Defaults” button since it removes any changes you’ve made to blade colour, volume or whatever and gives you a clean slate – after which the Proffie will create new save files as it needs them.

But looking at the other thread, it appears there’s a little more to it. So what are the gaps in my understanding of save files? When should we delete save files and when she we leave them? In what situations does deleting them cause problems and which scenarios see deletion resolving problems.

Thanks in advance.
:slight_smile:

3 Likes
2

By default, ProffieOS puts a timestamp in every config file. This timestamp is the time that ProffieOS was compiled. If the timestamp doesn’t match, it ignores the file.

This means that deleting the INI/TMP files shouldn’t be required, and if it is for some reason, you should start a thread about it.

Caveats

There are some caveats to the above.

  1. If you use KEEP_SAVEFILES_WHEN_PROGRAMMING then ProffieOS will read the files even if the timestamps don’t match. Don’t do that unless you know what you’re doing.
  2. If there is no timestamp in the file, ProffieOS will read the file regardless if KEEP_SAVEFILES_WHEN_PROGRAMMING is there or not. The only way to get a config file without a timestamp is to use a ProffieOS that is 4+ years old though.
  3. Corrupt files could cause problems even if ProffieOS is not really reading the files. In this case there may be good reasons to remove the files (or reformat the SD card) which are not really related to whether ProffieOS is ignoring the contents of the file or not.
3

Is there a good reason for not just ignoring them in this case? If keep save files is not present and the only way to get that state is to have a file that must be very old, it seems the sane default is to ignore them.

Especially since the Chinese sabers are still routinely using this version, it makes it a common annoyance for people upgrading from there.

I figure this is something you don’t feel like changing at this point though.

4

Originally it was done this way to be backwards compatible.
However, it may be time to re-visit that decision.

1 Like
5

My reasoning is even if there’s a time stamp on the program itself, and I would have to ask @Fett263 and @profezzorn how his EditMode plays into things, is that removing them (in the case where EditMode is a define, as it is in the other thread) prevents them being read and an old EditMode change being taken as current defacto. In the case of the other topic where a LED is still playing white and no confirmation a basic step wasn’t tried makes sense to then try it. It can’t hurt and I’ve seen situations even in OS 7.14 and .15 where leaving the tmp and ini files there affects the way things work.

*For any newb reading this DO NOT GO DELETING your config.ini or smoothswing.ini files. This refers to the following only:

curstate.ini
curstate.tmp
presets.ini
presets.tmp
global.ini
global.tmp

Everyone else, got it? Yeah it’s not “ideal” or “what is expected of the program” but also It’s like doing an oil change or your home HVAC system and not swapping the filter. Cargo Cult aside, in this case it applies simply as a means to eliminate the factor.

1 Like
6

All edits from Edit Mode are saved in the .ini files, so if you delete you remove your edits. As profezzorn already covered, the timestamp prevents the .ini from being used after new uploads so I don’t see a “need” to delete the files. I’ve never deleted them.

I would worry above telling new users to delete as I can see them deleting the wrong things and causing more headaches for themselves.

7

Generally speaking, deleting the ini/tmp files is safe if you do it right, meaning that you eject safely and wait until the OS is actually done before removing the device.

There are two more minor drawbacks to deleting the files:

  1. re-creating them takes time, you’ll notice ProffieOS hanging for a second or two the first time it has to save something.
  2. It’s an extra step, which makes it take slightly longer to do stuff with your saber.

There are two different kind of prooblems that can be caused by stale ini/tmp files… The first one is simply that your changes that you tried to make don’t work, because a savefile is overriding that change. The second problem occurs because of how presets.ini stores styles. The actual styles are not stored in presets.ini at all, instead it just stores “builtin X Y” where X is the preset and Y is the blade. If you change the preset table, then the locations of the styles changes and everything can get mixed up, and if you reduce the size of the preset table, then “builtin X Y” may return null in some cases, which can cause crashes. (Although I don’t think it does anymore, just black blades.)

8

A useful tool that we don’t have yet would be a tool that reads your preset.ini/tmp files and updates your config file accordingly. This would offer an easy way to keep any edits you’ve done with edit mode when programming the saber.

9

OK, I’m slightly confused…

If proffieOS adds a timestamp to a savefile, that must mean that it basically locks that savefile to a given upload. If you then upload a new config, the timestamps won’t match and ProffieOS will ignore the save file, but because the save file is present, it won’t write a new one, even if you have #define SAVE_STATE in your config.

Surely this means that if you upload a new config without deleting old savefiles, the system won’t save any subsequent changes you make in edit mode, volume, colour change or whatever? The only way to make saving settings work again is to delete the old save files which wil prompt ProffieOS to create new, valid ones? Or can ProffieOS actively update a timestamp in an existing save file to make it active again?

Or have I got completely the wrong end of the stick? :face_with_diagonal_mouth:

10

It will still write a new one.
Writing over the old save file is normal for ProffieOS.

1 Like
11

So if overwriting an old, invalid save file is standard, how can save files trip the system up? Is it only possible for a save file to cause problems if you use the KEEP_SAVEFILES_WHEN_PROGRAMMING define?

12

Isn’t this exactly what the CAVEATS section above explains?
If not, maybe I’m misunderstanding your question.

13

I shold maybe clarify that “ignoring” and “overwriting” doesn’t happen when you program the board. It happens during the normal “read” and “write” operations.

ProffieOS reads the config, usually at startup. This is when it “ignores” things.

ProffieOS writes the config when a change is made, for instance using “edit mode”, this is when overwriting happens. Note that for some configurations that don’t use edit mode, writing new configs may never happen.

1 Like
14

This has been brought up before and honestly would be what I would want users to have if possible for OS9.

This is a great topic and talking-point as it does give reason to re-learn flash steps and possibly can lead to improvement for all. Thanks for entertaining it! :smiley:

15

Thanks for clarifying. :+1: Also why I put that “don’t go deleting the smooth swing.ini” bit above. I’ve had to pull users out of a hole they dug themselves into following advise from others that shouldn’t be given and is why I personally gotta watch what I suggest in case a user screws-up as a result. I only brought it up for the scenario and it’s rare I even go there.

*We need GOOD people sharing this so the fact it’s in a topic here is great as a stepping stone.

**Given the chance of wider clarification needed I think the discussion or in your case PRESENTATION of the logic and steps would make for a very valuable video update to your channel. Thoughts?

16

I think such a tool would more likely be a part of the proffie master board project.

17

True and it’s another piece of this all. :slight_smile:

18

I don’t think users should delete ini files, especially if they’re not really knowledgeable in the whole process, hence why there’s no videos on the topic.

If we come across a user that has the KEEP_SAVEFILES_WHEN_PROGRAMMING define I typically tell them to remove unless they really understand what it does, I have a whole thread on this already.

19

OK, let me try to see if I’m getting this:

You boot your saber, ProffieOS compares the uploaded time stamp to the save file time stamp…

If the time stamps match, it uses the settings in the save file.

If the time stamps don’t match, it ignores the save file and uses the uploaded config settings.

If you subsequently never make any changes to your saber in edit mode, colour change, volume or whatever, ProffieOS will ignore the save file forever because the time stamp will never match. In other words the save file will be permanently invalid and therefore ignored in perpetuity through all reboots.

However the moment you do make any changes to blade colour, edit mode etc., ProffieOS overwrites the invalid save file and updates the time stamp in it so that it matches the config. This effectively changes an invalid save file into a valid one.

At this point, the uploaded config (which you’ve now edited) and the save file match.

This means the next time you boot the saber, the save file date stamps will match and ProffieOS will load the save file settings.

But…

All of this is subject to you NOT using the define KEEP_SAVEFILES_WHEN_PROGRAMMING. If you DO use this define, the save file remains valid even if you re-upload a new config. But if you re-upload a new config with, for instance, a different number of presets than is specified in your save file, then you’re likely to run into conflicts, and it’s at this point that deleting save files might save a misbehaving Proffieboard because once the old save files are deleted, the system will create brand new valid save files and everything will be back in sync.

Is that about the size of it?

2 Likes
20

Pretty much, so long as you’re on OS6 or later.

1 Like