Crash when filtering with Extr2Fsd driver

Help & Support
1

Hi,

first of all, I'm aware of this thread, but I have some technical details to add, and my issue might be different after all, so I'm starting a new thread.

I've installed the Ext2Fsd driver (version 0.51) in order to access Linux ext3 Partitions from Windows 7 64-bit. That basically works fine with DOpus 10.0.4.0 64-bit, but as soon as I enter something in the filter toolbar to filter the files displayed in the list view, DOpus crashes. Can there be done anything to work around the issue?

Thanks.

2

Do you get any sort of error dialog when it crashes? If you could post a screenshot that could be helpful.

Also if you can PM me a crash dump (Crash dumps for bug reports) I'll have a look and see if it tells us anything.

3

I just get Windows' usual "Application has stopped working" dialog, see the attached screenshot. Unfortunately, I have no %TEMP%\DOpus.Minidumps directory.

4

So you can display the directory correctly, but as soon as you try to filter it crashes?

How many files are there in the directory? Could you attach a listing of the files (use Tools / Print / Export Folder Listing)?

Does this happen in any folder or just a specific one on that device?
What pattern are you entering into the filter control?

5

Almost like that. The directory displays correctly at first, and filtering, too, but when I enter (about) the fourth letter in the filter toolbar, Opus crashes. It's not 100% reproducible regarding when exactly it crashes, but it always crashes at some point.

There are about 1200 files and 144 folders. Please find the listing attached.

So far I was only able to reproduce the crash with this specific folder. However, the other folders I've tried so far also have less files.

I'm trying to filter for "libicu".

Today, I suddenly got another dialog when I navigated to the folder in question and just waited some time doing nothing. The new dialog asks me to terminate an Opus thread, see attachment.


list.zip (20.5 KB)

6

What columns do you have displayed in the Lister?

If you have any columns enabled that cause Opus to open the file to extract metadata (like the Description column, etc) try turning them off. It may be accessing a particular file that triggers it. This would explain the filtering connection - once the list is filtered sufficiently, the file suddenly comes into view, Opus tries to extract the metadata and crashes. It would also explain why it will do it after some time without filtering, as the metadata is all being read in the background, and it just takes a while to get to that file.

7

I have the "Name", "Ext", "Size", "Modified" and "Attr" columns displayed. I tried to disable the "Size", "Modified", "Attr" and "Ext" columns one after each other in that order, but that did not help. Is it possible that a third-party shell extension is the culprit?

8

It's possible, maybe something that provides file icons or icon overlays and needs to examine the file to do so.

You could try using Procmon to see what the last file accessed is before the crash happens.

9

[quote="jon"]It's possible, maybe something that provides file icons or icon overlays and needs to examine the file to do so.

You could try using Procmon to see what the last file accessed is before the crash happens.[/quote]

Try turning on Preferences / Folders / Folder Display / Show generic icons for: All folders to check if it's icon-related.

(Using Process Monitor may still be useful, either way, to narrow it down to a particular file that's causing the problem.)

10

That did not help, but I was able to narrow down the issue to a single directory, and I guess I know now what the issue is: There's a /usr/lib/firefox-addons/searchplugins directory on linux, which contains a link "common" that points to ".", i.e. to the directory that contains "common". When calculating the directory size of "searchplugins" recursively, Opus is trapped in an infinite directory loop. It seems the Ext2Fsd driver exposes (Linux) links to directories as real directories (instead of Junctions or Windows Vista Symbolic Links), so there's probably no way for Opus to find out that "common" in fact is a link. But maybe this sort of recursion can still be detected in some way and a crash can be worked around?

11

Yes, we'll put in some protection to prevent this crash in the next version.

12

Great, thanks!