Ok, I was expecting that. Next week possibly I will have some time to look into that.

Thank you!

There is still support for nvme?

Deadwood, I took a screenshot when the pointer turns into a graphic artefact on Dopus. This should only happen with native WMware graphics (I no longer use VESA on VMware).

[quote name=deadwood post=10024]@deadwood - Ok, I was expecting that. Next week possibly I will have some time to look into that.[/quote]

I don't know if it's important, but I found that if I use Dopus4 from the Early Startup command prompt (boot menu), Dopus4 seems to copy without any problems.

I tried copying the entire AROS One 64 (2.3 GB) to RAM twice (see screenshot), and everything went well. The Dopus4 copy also seemed very fast (almost as fast as on native AROS).

The GURU problem with Dopus4 could be ‘trackdisk.device’.
I tried modifying the Dopus4 binary by removing the ‘trackdisk.device’ entry, and at the moment the Guru has not appeared despite copying a lot of data from the network share. I will continue testing!

If, on the other hand, I remove only the ‘trackdisk.device’ from DEVS, the Guru appeared only once. I will continue testing here as well.

This problem with DOpus4 looks to me like a subtle stack corruption problem (not too low stack, but damaged stack). This means different changes to how binary operates might hide or show the problem. Sometime even adding one line of debug in the right place can hide the problem (but not really solve it)

Can you point me to where I can download the smb2fs you were using with your tests on hosted (the ones where it was very easy to replicate the crash when reading from network share).

Can you also page the configuration you are using with smb2fs?

@AMIGASYSTEM

I reproduced your crash with smb2fs and locate the bug in asyncio.library. It was causing random memory to be used as buffer, damaging other software's data and would eventually lead to crash during or after copying data with DirectoryOpus.

Here is fixed library:
[url]https://axrt.org/development/asyncio.library-40.1.x86_64.zip[/url]

OK, thank you. I suspected that it might have something to do with asyncio.library. The solution I found by removing Trackdisk might work for those laptops where the floppy drive is not detected. In this case, Dopus4 cannot start, and the same thing happens if a floppy drive is not added to the configuration on VMware.

Does this build fixes copying issues for you?

At the moment, I haven't found any Guru in copying; among other things, Dopus4 now copies much faster.

I don't remember having already reported the ‘Move’ problem on Wanderer!

Basically, Wanderer does not allow you to move files or folders to overwrite existing files or folders, see screenshot.

If you change the function from Move to Copy in Wanderer preferences, the overwriting works correctly!

There is also another problem if you try to delete a folder full of files and folders in Wanderer. In some cases, you have to repeat the command. Basically, the first command empties the folder and the second command deletes the folder.

These problems are also present in the Builds to be tested.