Problems with the folder structure in the elements folder

From SuperMemopedia
Jump to: navigation, search


If you suspect a damage to your collection and the File : Repair collection says No errors, you can use F11 to review your collection visually for ultimate reassurance.


Terrance asked:

I began searching here looking for reasons why repair was not fixing the registry mismatches. I understand that the problem may not be in the folders here, but in the actual registry files themselves. I have not gotten far enough to compare them yet. I don't know how to properly open them even though I have a decent editor in visual studio. I have not deleted anything, and have many backups, so I am not worried about messing anything up. I noticed that most of the numbered folders within supermemo\elements\* contain 10 elements, as seen in the images I link to:!5980!5981!5978!5979

2 of the folders ( supermemo\elements\1\* and supermemo\elements\2\* )do not. They contain many other folders and many other elements, again, most of which contain 10 elements like in the picture above. I feel like something is wrong. It just doesn't sit right. I remember some time ago selecting to have supermemo process something so that each folder contained 10 elements. I don't remember how to do this. A second time I did this, I think the elements were moved into different categories. What can I do to have the elements sorted into folders for their respective categories. I have included a set of images of my file structure. I have also included a link to my skydrive folder which contains my supermemo folder and everything in it.

In summary: I understand the basis behind the other files. I would like to move elements to folder structures in common with their categories. Also, whether or not that can be done, I would still like to understand what is going on in these folders, at least enough to be able to explain it in a video. Thank you. Terrance Wickman


  • the \elements folder structure has nothing to do with the knowledge tree and better be not tinkered with or even looked at (due to unnecessary confusion). It only serves as a filespace: a complex container for many files. The structure is just based on complex combinatorics that probably only its author understands. Build your knowledge structure in Contents. What happens in \elements will have little or no connection what happens in the knowledge tree.
  • registry files also would better not be played with as this is likely to result in errors/damage. The definition of the files has probably not been published. They serve as an internal database that is best handled by SuperMemo itself.
  • the described folder structure in your collection looks normal. It may seem chaotic as it is optimized for access. There is little information of value for the user in that folders structure (except for the files that are also best access via SuperMemo). It might be compared to a fragmented file on a user's hard disk. The information in the file is useful, but how it is spread all over the hard drive in individual sectors is uninteresting (in this case, the data structure is best handled by the file system in Windows).

Follow Up

With all of the negative comments on here, I did not expect such a fast response time. Thank you. Now it seems as though I do not need to understand specific details of how a particular element is where it is in the \elements folder. I probably did not make this clear, but I will try to now. I am trying to solve a discrepancy between the registry and the actual contents of that registry. For example, 2120 files in a 3200 file system. After viewing the particular registries from within SuperMemo, a discrepancy should not be reported. I attached the entire collection, which included the repair logs. As can be seen, many instances of this problem occur. Telling supermemo to delete the unused items from the particular registry has no effect either. I am trying to solve the problem at its root, by finding any differences between the registry contents, and what is actually in my folders. Can you suggest a better way? I am not worried about messing up SuperMemo as I have several copies of the whole thing. I make them after every study session, before and after running a repair, which I do every day. I sent an email in a while ago asking if doing repairs this frequently is ok, or if repairing is just as error prone as the program itself, and running it more repairs leads to increased chances of having a problem. If I knew more, I would also be able to prevent this type of thing from happening in the future. And then I could tell other people some best practices when creating elements. Without this information, I cannot tell them how to prevent this type of thing from happening. Thanks you, Terrance Wickman

P.S. Thank you for you candid response. I know you must get many repeated questions. I have looked into this error, searching both google and supermemo, and folling the suggested fixes, but none of them seem to work.

More hints

  • Delete unused will not work in some registries where content is not added automatically (probably templates, categories, etc.). For example, you may create template for later use, and these should need no clean up even if they are reported as use=0. If this behavior never changes, those menu items would indeed better be disabled/grayed
  • like there is little relationship between the knowledge tree and the filespace, there is equally limited correspondence between the filespace and registries. For example, some texts have no formatting and will not appear in the filespace, while others may be peppered with icons and include dozens of files that will land in the filespace increasing the file count
  • the best way to submit collections for inspection is via mail to bug (year) AT supermemo DOT com as a ZIP file (unless they are for public viewing)
  • the repair report dated March 25, 2013, 10:46:51 PM looks healthy. As for Rebuilding Text registry (1212 members in a 1313 member file), please await a response in a separate entry (it probably means that the size of the registry file shows 1313 members of which some 100 have been deleted and not reused, i.e. that message does not refer to the filespace). See: Why do the number of files and registry members differ?
  • to get a better answer to those technical questions, you will need to wait a bit longer (docs or even the code need to be checked to clarify things)


Your collection seems to be ok. When you run File : Repair collection, always focus on the message at the bottom. In your case, it says No errors.

Complexities of filespace or registry indexes should not obscure that summary and may not always be worth investigating.

Warnings in the report as usually also not worth investigating unless you are curious of how SuperMemo works (some warnings may not be documented and you may need to use this wiki to inquire).

Note that repairs may not detect corrupt data in texts, pictures, or other files. SuperMemo does not keep file checksums. The only way to spot such problems is to review the collection (corrupt files will show as garbled texts, or distorted pictures, etc.). If you suspect a problem, use F11 for a random review until you are reassured all is ok (e.g. after a power failure).

Repair collection is a good collection checkup. There is nothing wrong with doing repairs daily, esp. when you are new to SuperMemo. However, later on, you could save time by doing checkups monthly, esp. after a crash or power failure or when you suspect a hardware problem. Larger collections can take pretty long to check up on slower PCs, esp. if you do a full lexicon rebuild.

For more see: Why do the number of files and registry members differ?