Opus 8 destroys my descript.ion files

I was excited to find a modern file manager that supports descript.ion :slight_smile:

However, it quickly turned into despair when I found that Opus 8 trashed the descript.ion files :frowning:

  1. For example, I have a directory with 15,000 images and a descript.ion file (~3 MB)

  2. If I open this directory in ACDSee (v3.1), Magellan Explorer or Total Commander, the directory opens within 1-3 sec and I can read the descriptions.

  3. If I open this directory using Opus 8 (v8.0.1.2) with descript.ion support turned off, the directory also opens within 1-3 sec.

  4. If I enable descript.ion support in Opus 8, it takes "forever" to open the directory. After 30-60 sec of waiting, I click on "abort".

  5. If I now look at the descript.ion file, its size has shrunk from ~ 3 to 1 MB, and many of the descriptions have dissapeared (e.g. when viewing with ACDSee).

I have trahsed several descript.ion files before I discovered the problem.

This is a very serious bug :confused: :confused: :confused: !!!


After some research, I found out why Opus trashes the descript.ion file:

Every time Opus opens a directory, Opus rebuilds the descript.ion file (provided that descript.ion support is enabled).

This can take a very long time. In my case up to several minutes with a directory containg 15,000 files described by descript.ion.

This is not the case with other File Managers that support descript.ion (e.g. Magellan Explorer or Total Commander) because they do not rebuild the descript.ion file each time a directory is accessed. Thus, the directory opens instantly instead of taking several minutes.

Furthermore, if the opening of the directory is aborted in Opus (I got impatient after waiting for > 1 min), the rebuilding of the descript.ion file is incomplete and data is lost.

This is a very serious bug that should be fixed. However, word from the developer is that it has very low priority because noone else has reported it..... :frowning:

Are there no other users out there with the same problem?

It's happened to me a time or two but each time I just assumed I'd somehow inadvertently deleted the descript.ion files although I couldn't figure out what I had done to do so. Fortunately each time I had a backup handy so I was able to restore the files.

If what you say is right, and I have no reason to doubt it, then I agree this is a rather serious problem (for those of us who rely on descript.ion files) and I hope that it will be corrected.

It's not strictly true that Opus rebuilds the descript.ion file each time. When Opus loads the folder it attempts to match each description entry in the .ion file to a file in the folder. At the end of the process, if any descriptions did not match (ie, the files they were describing no longer existed), the descript.ion file is resaved with the unneeded descriptions removed.

What's happening in this case is, because you're aborting the directory read halfway through, Opus is left with a list of descriptions that had not been matched to anything, and so figures it can just go ahead and clean up the description file.

I agree this is a problem and we do have a fix for it now. We also have a fix for the slowness you were experiencing in here (the descriptions were being looked up in a simple linked list, so the time increased exponentially as the number of descriptions increased). I've changed this to use a hash table lookup so even with a very large number of descriptions in the file it should not take a significant amount of time to match it up.