Filer, from OpenAmiga.org

@orgin

Hi, I found the problem
I have to change following in the gui prefs:
Options -> Active (and inactive) window transparency to 1% (or more). Or I have to deactivate the "Compositing mode for layers (3D...).
Then it works fine! Now the same problems with DiskMaster are gone, too!

Thank you very much!

Heiko

@gurus2000

Quote:

Now *that* sounds like a bug in intuition!

@broadblues

I think so, too!

@gurus2000

That particular "feature" has been fixed already in the beta version of Intuition.

Simon

@orgin

Hi Orgin! :)
I have one question - is any chance to implement os4 procedures for copy function? On classic hardware system function (with AsyncWB) is more faster than used in Filer. Maybe is possible to change it using tool types? Greets and thanks for greath work!! :)

@Lokaty
If that is true, then it is more likely that Origin just needs to use a larger buffer for copying. Also, I don't think there ARE any OS4-specific "copy routines".

@ChrisH & Lokaty

I'm using IDOS->FRead(src, buffer, 1, COPY_BUFFER_LEN).

What would be a good value to set COPY_BUFFER_LEN to ?


(Although since it's buffered, does it really matter?)

@orgin

Not sure, but maybe it's the buffersize in IDOS->FOpen() that you would need to increase? Although unhelpfully It says 0 = default in the autodocs without specifying what that default is.

The COPY command docs says it uses a default buffer of 200 x 512 byte blocks so perhaps that is a guide.

[edit]
I notice that DOS prefs has a filehandle bufsize entry and that is only 8kb.
So presumably that is the default refered too.
[/edit]

To honest though, filer seems to copy moderately fast for me, faster would obviously be better but it's not problemetically slow here.

@broadblues

"maybe it's the buffersize in IDOS->FOpen() that you would need to increase?"

Perhaps. But anyway, if someone has some good figures I'd be happy to put them in there.

@orgin
I once did some test with OS3.9 (probably on Amithlon or WinUAE), and found a 0.5MB copy buffer to be close to optimal. However, different h/w, different filing system & different OS could easily mean that is no-longer best (I personally suspect a larger buffer would be needed, but daren't do so without some tests to prove it).

@orgin

*scratches head* wouldnt be the source device buffer size the optimum? I mean, you read the whole device buffer into your own buffer, so the device may use any readahead features (like sfs do) to fill the device buffer "instantly" and you will have next copy data ready to transfer into your own buffer when your write cycle is done... but what happens, if read and write device are the same?... *scratches head again*

Regards

I found/rediscovered another probem with Filer being launched by the ContextMenus commodity - Filer has a priority of +1, rather than 0 as normal. So I've modified my script to look like this:
Quote: