Filer, from OpenAmiga.org

@Snuffy

I just searched #?a#? on dh0: without any problems. Returned 5524 entries.

Do you really believe that I haven't tested recursive searching like a thousand times during development?

You still haven't provided a complete crash log from the debug version.

@orgin
I hadn't noticed any problems with "Find..." BUT I had noticed a problem with recursively copy large numbers of files/folders - Filer tends to crash after a while, so I have to use Workbench instead for such copying

@ChrisH

Unfortunately it never happens here so there's not much I can do. I've copied the whole sys: more time than I can remember.

Different setups and os4 versions behaving differently is getting quite annoying...

@orgin

Hi!
I've just tryed filer after few months and it seems to me really progressing :)
Only two thingI think it lacks to be a default filer for my WB:

1(much important) drag&drop functions(at least from filers)
2(less important) a bubble help to explain buttons

another thing to add

3(less importatn but nice to have) thunmbnails option for pics and more display options for the files (column/icon/etc etc)

excusme if that was just discussed...I'm tryed the filer as mentioned only today after few months...

However GOOD WORK!

@Tuxedo Quote:
This is a limitation of AmigaOS, which only Hyperion can fix. (Although maybe drag'n'drop BETWEEN Filers is possible? Also drag'n'drop from Workbench to Filer should be easy to implement.)

My work-around is to use the "Lister/Workbench folder" menu option to open a Workbench window of the current Filer folder, and then use THAT to drag'n'drop from.

I also have set-up the "ContextMenus" commodity (as described in some previous posts) to provide an "Open in Filer" menu option for Workbench. This completes the circle, and allows me to switch to Filer when Workbench is not ideal.

@orgin Quote:
Just tried copying my Sys partition, and it did indeed crash after a while. I have a crash log if that would be any help? It says "Redzone was damaged, Stackpointer is out of bounds (guard area hit)".

Here are probably the most relevant parts:

Crash occured in module kernel at address 0x0143BEC4
Type of crash: DSI (Data Storage Interrupt) exception

SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F030
Condition (cr) : 0x28022044
Instruction Pointer (ip) : 0x0143BEC4
Xtended Exception (xer) : 0x00000000
Count (ctr) : 0x0143BEC0
Link (lr) : 0x0143BFC4
DSI Status (dsisr) : 0x00800000
Data Address (dar) : 0x547D1FE0

Symbol info:
Instruction pointer 0x0143BEC4 belongs to module "kernel" (HUNK/Kickstart)

Stack trace:
native kernel module kernel+0x0003bec4
native kernel module kernel+0x000136f8
native kernel module kernel+0x00013690
native kernel module kernel+0x00011e70
native kernel module kernel+0x00011fcc
native kernel module dos.library.kmod+0x00010f20
native kernel module dos.library.kmod+0x00032ee8
native kernel module dos.library.kmod+0x00033770
native kernel module dos.library.kmod+0x00014350
native kernel module dos.library.kmod+0x0000c5d8
native kernel module dos.library.kmod+0x00038a00
module Programs:Workbench/Filer/Filer at 0x6E857970 (section 5 @ 0x15950)
module Programs:Workbench/Filer/Filer at 0x6E8542F4 (section 5 @ 0x122D4)
module Programs:Workbench/Filer/Filer at 0x6E8571C4 (section 5 @ 0x151A4)
module Programs:Workbench/Filer/Filer at 0x6E856A9C (section 5 @ 0x14A7C)
module Programs:Workbench/Filer/Filer at 0x6E8572CC (section 5 @ 0x152AC)
module Programs:Workbench/Filer/Filer at 0x6E856A9C (section 5 @ 0x14A7C)
module Programs:Workbench/Filer/Filer at 0x6E8572CC (section 5 @ 0x152AC)
module Programs:Workbench/Filer/Filer at 0x6E856A9C (section 5 @ 0x14A7C)
module Programs:Workbench/Filer/Filer at 0x6E8572CC (section 5 @ 0x152AC)
module Programs:Workbench/Filer/Filer at 0x6E856A9C (section 5 @ 0x14A7C)
module Programs:Workbench/Filer/Filer at 0x6E8572CC (section 5 @ 0x152AC)
module Programs:Workbench/Filer/Filer at 0x6E856A9C (section 5 @ 0x14A7C)
module Programs:Workbench/Filer/Filer at 0x6E8572CC (section 5 @ 0x152AC)
module Programs:Workbench/Filer/Filer at 0x6E856A9C (section 5 @ 0x14A7C)
module Programs:Workbench/Filer/Filer at 0x6E8572CC (section 5 @ 0x152AC)
module Programs:Workbench/Filer/Filer at 0x6E856A9C (section 5 @ 0x14A7C)
module Programs:Workbench/Filer/Filer at 0x6E852BAC (section 5 @ 0x10B8C)
module Programs:Workbench/Filer/Filer at 0x6E85258C (section 5 @ 0x1056C)
module Programs:Workbench/Filer/Filer at 0x6E867A54 (section 5 @ 0x25A34)
module Programs:Workbench/Filer/Filer at 0x6E847EC0 (section 5 @ 0x5EA0)
module Programs:Workbench/Filer/Filer at 0x6E84D46C (section 5 @ 0xB44C)
module Programs:Workbench/Filer/Filer at 0x6E842914 (section 5 @ 0x8F4)
native kernel module newlib.library.kmod+0x00001f38
native kernel module newlib.library.kmod+0x00002b84
native kernel module newlib.library.kmod+0x00002d48
Filer:_start()+0x170 (section 1 @ 0x170)
native kernel module dos.library.kmod+0x0001ea6c
native kernel module kernel+0x000360d0
native kernel module kernel+0x00036150

Could this be a stack issue? Filer looks rather recursive to me... Why not use a list for recursion? I should note that this issue is not always repeatable for me, but it does seem to happen most often on deep directories, e.g. when copying the tiny file "Programs:Old/Apps/PaintPacks/PfPaint/RayLabFactory/Fonts/Light.rlf".

@ChrisH

ok!
that's usefull...
naturally the only other way to "fix" it was to use MUI interface for filer but I think that not possible...
Hope that Hyperion will put drag&drop asap :)

@Tuxedo
Reaction has nothing to do with it (at least I think Rigo added drag'n'drop support to Reaction), but rather it is that only Workbench is allowed to start a drag'n'drop operation. There is a proposal to Hyperion on OpenAmiga as to how they can fix that.

@ChrisH

ok!
thnk you!

@orgin
BTW, is there a reason that Filer runs at a priority of +1 ? This causes everything else (e.g. OWB) to slow right down if I am doing heavy copying or some other such function. Workbench runs at priority 0 I think.

@ChrisH

Quote:

How much stack do you have set? The icon has 32k, but my global stack is 72k and I've never hit a crash like that. I've moved some pretty big source trees arround, with filer.

But if filer is using a recursive copy routine, then it's going to run foul of the stack at some point.

@ChrisH

"BTW, is there a reason that Filer runs at a priority of +1 ?"

I've never set the priority. Is +1 default in some way?

"Could this be a stack issue? Filer looks rather recursive to me... "

Try increasing stack then. Though it seems odd that it would use more stack on some systems than others.

@orgin

The OS4.1 default minimum stack size is ridiculously low IMO (just 16 kB). I've increased it to 80 kB on both my SAM and my A1.

You could use stack cookie to set the minimum stack size for Filer. In my experience this is much more reliable than simply setting the stack size on the program icon.

@orgin
Priority:
Filer normally has a priority of 0, but it has +1 when it is launched by ContextMenus. Could you add a work-around?

Stack:
"Status FULL" can be used to check how much stack is allocated. If Filer is launched by FilerCx (double-click Workbench), then it has a stack of 20472 (as does FilerCx itself). Same when launched by it's own Filer icon. But all the icons specify a stack of 32768, and increasing this by 10 times makes no difference! I notice that Prefs/DOS specifies a "Process stack size" of 16KB if that makes any difference.

Note that if Filer is launched by a ContextMenus menu option, then it has a stack of 40952.

So it seems likely that it's stack is usually 20472, which is rather low, and could easily be causing stack issues with recursion.

@ChrisH

I notice the filer icon is set to run from the shell. Setting the stack in the icon has no effect in this case. Whether that's a bug in the icon handling or an undocumented behaviour I'm not sure.
If you default stack is alow as 16k you should increase it, not just filer will be unstable with that little stack. PPC programs need more than 68k and the "default default" should be higher IMHO.


@orgin

Is there a reason for the icon being set from shell?

@salas00

You need a \0 in that stack cookie ... ie

static const char USED stack[] = "\0$STACK: 81920";

@broadblues

Quote:

Yes.

@orgin

Quote:

That's okay then Just checking incase it was an oversight....

You need to be aware in that case, though, that you can not set the program stack from the icon when shell is selected, and it will use the default stack size / or the value set by the stack cookie / other stack upgrading tecnique. In any event it doesn't seem to be safe to reply on the user to set the stack intelligently....

@orgin

I'm getting some anomalous behaviour from FilerCX WRT to double clicking on the workbench.

When I first boot often double clicking doesn't work. To get it to work I have to either bring up Exchage (or any commodity such as Srec or Sgrab) via it's hotkey or, select a few icons via the tab key, then deselect and double afetr that. Once a filer has opened double click always works,

Happens after a soft or hard boot, I'd gestimate 70% of the time

Anyone else see this?

@broadblues

Here's the source, have fun ;)

http://orgin.biz/~orgin/filer/launcher.zip

@orgin

Just in case anyone was wondering. Development will be halted a bit during summer, I have some outdoor stuff to take care off during the summer.

If you need something fixed quickly then let me know and I'll see if I can find some time.