Bugs in latest stable 13.5

Help & Support
1

Hej There,

seems, that 2-3 misbehaviours of the later 13.4 Betas found their way inside the actual 13.5 stable. I Got rid of them with going back to 13.4 stable.

  1. placed rename setting (rename every word 1st letter upcase) in shortcutbar. Selecting files and clicking that won't do the job. Selcting the same function inside rename windows works.

  2. having in the right pane a subfolder from the left pane and dragging files from left to right copies instead of moving files.

  3. generally a manual refresh (F5) has to be done oftenly as DOpus doesn't recognise changes as usual. For example external moving by teracopy, or internal renaming or deleting files --- leaves the panes unchanged.

All that works like expected by going back to 13.4 stable.

greets, Karsten

2

#1+2 work fine for me, #3 seems ok as well, although that's a bit more difficult to assess.

1 Like
3

Can't reproduce #1 or #2 here either. You say they were problems in the betas but I don't remember them being reported previously?

#3 does get reported periodically by people, we aren't sure what triggers it, but restarting Opus usually makes file changes start working again.

4

Hello both of you,

tried again

#1 is being solved by F5, #2 + 3 still persists, even after restarting.

regards, Karsten

5

  1. What is the command that you're running? What do you mean by "clicking that won't do the job"? What happens?

  2. Is down to your file type, drag & drop event settings. Have you changed those? Are the source and destination folders on the same drive or different ones? Are you holding Ctrl/Alt/Shift while dragging?

  3. Changes to folders are not being detected has suggestions.

PS: Please Ask one question per thread

6

Hej Leo,

Rename PRESET=!list,favesonly
@nodeselect

by the way, I actually assume, that this is a refresh ting, too

  1. Settings are standard, no qualifier key pressed, works as expected by going back to 13.4 without changing anything else. And yes, in the right pane is a subfolder of the folder on the left pane, definetly.
    As my Dopus remembers all tabs and folders being shown as DOpus is being closed and opened again it's quite simple...

  2. thanks for hint, will try to check that .... the only thing I'm wondering about, is by going back to 13.4 the refreshing thing immediately works. Going up to 13.5 automatic refresh breaks. Going back then .... works

PS: sorry, will remember that :slight_smile:

7

Did some testing after an uninstall of DOpus, fresh reinstall of 13.5 (stable) and importing my settings...

  1. It seems like the drag'n'drop generally changed behavior on drives not having a drive-letter or UNC-path. Doesn't concern two panes, also happens if I drag'n'drop in the same pane:
    grafik
    I just dragged the "~Filme"-folder one entry down on the "~Spiele"-folder.
    For explanation:
    I changed the appearance of additional drives within windows drive-management from having a driveletter to being attached in a subfolder some time ago.
    grafik
    grafik916×312 77.1 KB

    13.4 stable didn't have problems with that, actually it doesn't work anmore like used. Inside lettered or UNC-drives it works like expected
  • moving with DOpus (right mouse - move) takes the same amount of time, as the target would be on a different drive
  1. the refresh thing also persists after clean reinstallment. I've checked the settings you mentioned above in the seperate link. Some tests I've did:

  • renaming by using mp3tag (move from displayed folder to subfolder) - works

  • renaming without moving file with mp3tag - works

  • renamed displayed file by "advanced renamer" - doesn't work

  • renaming displayed file by Windows explorer - doesn't work

  • unpacking file with winrar in displayed folder and deleted rarfile within winrar - doesn't work

  • downloaded file in displayed folder - doesn't work

  • deleting,renaming inside Dopus - doesn't work

all "doesn't work"-things are coming up by pressing F5

8

Focus on the FAQ I linked to, and solving the refresh issue. What do the debug logs show?

9

I've made a debugview++ log for you and will send that by pn.
renamed a test.jpg to xxxxxxx.jpg, refreshed manuallly and moved to subfolder "new folder" - then refresh that one.

10

Thanks for the log.

Looks like you're using mount points instead of drive letters in some places?

If the issue is only happening below those, I think we already have a fix coming for that.

11

thanks for the possible solution.
Yes, mount points, like I described aove... :slight_smile:

btw... support from You and Jon is great!

12

Thanks! Please try 13.5.2 once it's out, and let us know if there's still a problem.

13

Hej,

tried now 13.5.2.

seems to be solved: the refresh-thing. Thanks!

unsolved: the misbehaviour with copy/move by drag'n'drop on drives used by mounting points

generally, as source and destination is on the same mounting point drive it will be handled like being on different drives.

  • standard behaviour is copy instead of move
  • forced move (by SHIFT) will slowly copy and then delete after finish
14

Please give an example source/destination folder pair, with detail of which folders are mount points and what they point to.

15

Hej Leo,

source is "C:\extern\Seagate16TB\231127", destination is "C:\extern\Seagate16TB\231127\New Folder"
Did a Debugview++.log (look for "test.nfo", which follows by PN. Wonder why the "test.nfo" is reported as "test.nfo.txt" inside there... desired Drive is being listed with Objectname "\?\Volume{77AE16C1-DB5E-466D-B80E-8AEAE740994F}" inside Drive manager.

16

Many thanks! I've reproduced the issue, and we should have a fix in the next update.

That's a separate file, and inside the ExifToolCache folder rather than the folder with the issue.

It's probably from the ExifTool Columns script add-in, caching information about the real file.

1 Like