I'm running Doors CS 6.1.0, and every time the calculator RAM CLEARs, I lose all of my folders. Any help?

Nope, sorry. That's a problem on the DoorsCS end, not yours. There was talk about trying to save the folders, but it seems like we're going to have to learn to deal with it.

Let's hope DCS7 deals with it...

The debate is whether to archive folders and to force a rearchive of archived programs that are put into folders, or not. Any thoughts?

I don't see it as a huge deal. Perhaps a more convenient method would be keeping a backup of the folder info in the appvar to recreate them after a crash?

That's been proposed as well, and that's the secondary option I am considering. It has the disadvantage of complexity but the advantage of requiring less wear on the archive.

how do folders work? do they just contain the necessary info to locate their contents in the VAT?

Folders comprise two pieces:
1) Individual programs named %FLD#, where # is a byte valued from 1-255. 0 would be meaningless, 1 is the desktop (and therefore only exists as a placeholder to show that the DCS filesystem has been initialized), and 2-255 are normal folders. The sole contents of the program is a string, 1-8 characters
2) Normal programs, whether protected, archived, both, or neither, are given a T2 (secondary type) number that corresponds to the folder number that the program is in. 0=uninitialized, 1=desktop, 2-255=folder.

You mean you set the T2 byte in the VAT?

That is correct.

If you're storing folder information in programs or appvars, yes, back that stuff up to the archive, like what MirageOS does.

I highly recommend a feature to fix existing archived variables so that their T2 byte matches the RAM copy of the VAT. It requires Flash unlocking, of course, but I really think it could be done in a clean and stable way. It wouldn't be all that different from garbage collecting (except that it's far less wear and tear on the Flash than garbage collecting).

I'm happy to archive the folders, but they'll still be empty on RAM clear unless, as you say, I sync the T2 information. What's involved in the Flash unlocking - can DCS do it itself without fancy trix?

hmm... A B_CALL maybe?

Ah, so you're suggesting a fix such as saving a sector to the swap sector, erasing the original sector, and writing back with the correct T2 bytes?

...I still don't see the problem with rearchiving when you move a program to a new folder, though...

Edit:
You're also going to have to rearchive when renaming programs... what's the big deal?

Yes.

Unarchiving and re-archiving a program is a gigantic waste of time and wears out the Flash chip to make such a simple change. You risk triggering a garbage collect every single time. You need to keep in mind people already have hundreds of programs on their calculators with incorrect folder information and they're going to want a way to fix it without doing something to each and every single one of them. Unarchiving and re-archiving would be insane in that case. If you're going to invest the time in implementing something like this, I think going about it this way is best.

Yes, there is a universal Flash unlock exploit which works on all OSes and versions of the boot code and is unlikely to ever be fixed. It's been distributed in several places...off-hand, Chameleon, Free83P, etc.

Unless Kerm added multiple program selection without my knowledge, they are going to have to do something to each and every one of them - that is, move them into the folder.

Edit:
Also, each time this happens (like you said), there is a chance of garbage collection. You're acting like it's going to happen every time. By the way, in your plan, you do two (or three) Flash sector wipes per program moved! And wouldn't this brute-force flash handling destroy TI-Nspire compatibility, unless you add in separate code and a way to detect whether you're actually running on an Nspire in the first place? If you're going to have to rearchive for name changing (which is a one-time thing), why not for moving to folders (also a one-time thing)? It's definitely no more wear-and-tear than when MirageOS runs programs in general.

Two or three Flash sector wipes per program moved is insane. All I was talking about was a single "Fix All Archived Programs' Folders Entries" feature that, when run, would go through every Flash sector and fix anything it needed to. We're talking at most one sector wipe for each sector each time the feature is selected.

The same feature could be used to fix renames (or anything else inconsistent between the VAT entry and the archived copy). A garbage collection doesn't wipe sectors every time it deals with a variable, it handles a sector at a time. TI's crazy, but they're not that crazy...it takes time to erase a sector and they try to keep it to a minimum.

And no, this won't destroy Nspire compatibility (there are separate routines you must use, but it can all be wrapped to use either one or the other depending on which calculator you're running on (and you can detect whether you're running from within the Nspire emulator)).

hmm.. well, as is obviously known about my asm skills, or lack there of.. I could offer a solution I would do in basic.. xD Why not have an appvar, or use the current one and just be at the end of it, and use it to keep track of folders and what goes in them? Would that not be an easier solution?

That's one thing I considered, but it's quite an awkward solution. I'd rather have filesystem information embedded in the programs themselves rather than have to consult an appvar-based table every time I tried to figure out what programs were in each folder. I like Brandon's idea; perhaps do a folder sync on every DCS quit? Of course, it would only write back a page if it found changed items.

ah, alright. *shrugs* just tossin an idea out there. XD