Bug: Some files can't be forcly deleted (UAC appears)

Try the following:

  1. Download thunderbird installation file directly to a NTFS formatted partition
    download.mozilla.org/?product=th ... in&lang=de

  2. Enable the viewer pane to be shown in docking mode.

  3. Select the thunderbird installation file to let it be opened by the viewer pane in hex mode.

  4. Press SHIFT+DEL to forcly delete the file using DOpus (command "delete shift").

  5. The UAC appears asking you to permit this action.

  6. Press No to discard the UAC.

  7. Close the viewer pane.

  8. Try again to forcly delete the file.

PS: Point 2 & 3 are vitally important, otherwise the UAC won't appear.

I guess you've manually edited your text/hex viewer config to make it open files larger than 10MB?

I don't think it is Opus itself locking the file there. It is most likely your anti-virus, still inspecting it (which some virus scanners spend a long time on with some installers), since the Opus hex viewer does not keep files open. Or you've still got the installer running in the background, perhaps. (Note that some installers stay running for a while after they appear to have exited. Opus's own one does that, in fact. Seems to be something some InstallShield installers do, presumably waiting to clean up some temp-files or something.)

Since the probem can be easily fixed by just closing the viewer pane, I'm pretty sure that it depends on the viewer pane (in fact I made a dry run without a virus scanner installed).

Leo, please try it out by yourself. It just takes a few minutes.

Indeed you have to remove the file size limit by right clicking in the viewer pane to configure the text plugin properties.

I did try it.

If I select the Thunderbird installer you suggested, the viewer doesn't display it at all as it is too large (and I can't configure the viewer to show a file larger than that as 9999 KB is the max the UI allows me to put in).

If I try with a smaller EXE, the viewer shows it as hex; I click shift-delete, the file is deleted.

So I don't think the problem is the viewer itself locking the file, unless the text/hex viewer only locks large files, but I can't configure it to open such a large file in the first place.

Sorry, for that. You have to remove the value (empty the field).

It's important to use a file that was recently downloaded due to the NTFS flags.

Thus, please remove the value, download the file, select the file to view the content in the docked pane and then press SHIFT+DEL to forcly remove it.

This bringt the UAC to the front on a clean and fresh installation in my virtual test machine without any virus scanners installed.

After closing the viewer pane, I can instantly delete the file, after opening the viewer pane again the UAC is back. Strange!

By the way: Removing to the recycle bin always works instantly.

Leo, I take the time to have another dry run:

  1. I installed Win7 Ultimate 64bit to our test machine.
  2. I installed DOpus keeping the default configuration.
  3. I activated the docked viewer pane (BTW: the file size limit isn't set by default).
  4. I downloaded the mentioned Thunderbird setup.exe to the desktop (3x times).
  5. I selected the first file -> hex content was shown in the viewer pane
  6. I pressed SHIFT-DEL and clicked ok -> UAC appeared.
  7. I closed the viewer pane.
  8. I selected the second file
    9 I pressed SHIFT-DEL and clicked ok -> file was removed.
  9. I activated the viewer pane again.
  10. I selected the third file -> hex content was shown in the viewer pane.
  11. I pressed SHIFT-DEL and clicked ok -> UAC appeared.

Same problem here. It's not possible to SHIFT-DEL the file if it was recently downloaded and the content is shown in the viewer pane.

Initially I recognized that problem, when moving files around. It is the same bug.

Instead of SHIFT-DEL the file, please try to move the file to an other partition. In this case the file copy dialog appears, than the UAC comes up (I accept) and finally an error dialog is shown saying that the file can't be moved since it is locked by a process. And in the process list only DOpus itself is listed.

This bug only occurs if the content of a recently downloaded file is shown in the viewer pane. Maybe only exe files are affected.

Thanks for the extra details!

I've found and fixed the problem now.

The text viewer keeps the file open if the file is larger than 2MB (the file I was trying with was smaller, and I didn't realise the size limit was optional or off by default, but you're right about that), and it wasn't being closed at the right time when the delete happened.

Sorry for my incorrect theories above. I didn't realise the text viewer did this with larger files.

The fix will be in the next beta version.

Leo, thank you very much for the customer-friendly support (and quick as always) ...

[quote="leo"]Thanks for the extra details!

I've found and fixed the problem now.

Hmm, during my tests related to the newly introduced copy mode (unbuf) I saw several UAC dialogs if the viewer pane was docked and I tried to delete a 10 MB file.

If I close the viewer pane the UAC doesn't appear anymore.

Here is a screenshot ...

Does it only affect (multi-part) RAR files?

Will have to keep an eye on that.

I can reliably reproduce that for the first 20 parts of a multi-part rar file.

The 21st part can be deleted immediately.

Does this help?

The hex viewer would not care if the file was the 20th or 21st part of a split RAR archive, but something else may be scanning the contents of the archive, perhaps.

You say it doesn't happen after the 20th file, but your screenshot shows the 31st file?

Yes but you can see the scrollbar at the right and the 31st file actually was the first one. The 30 files before were removed in the step before.

But it may be a race condition or something similar, because in my last test I can even delete the 4th but not the 5th.

Anyway it can be easily fixed by just closing the docked viewer pane. Afterwards the file can be successfully deleted.

Permission denied dialog just appears here when trying to move a quicktime file which content was shown in the viewer-pane.

I can click "retry" as many times as I want without any effect.

To fix that I just have to select a different file (viewer pane was updated) and click retry.

Video files may be locked open by the video player, and we're not always able to close them in a timely manner.

The viewer tries to release files when needed, and many of our own viewers try to avoid keeping files locked in the first place, but it is not always possible with every filetype, especially when 3rd party code is involved. It's never going to be perfect. Just close the viewer if it's causing you problems, especially with video files which involve codecs that do all kinds of crazy things. :slight_smile: