@orgin

Since the latest update the filer doesn't update it's list when creating / deleting copy files. This applies to *all* filers not just ones listing usb, in fact I have no usb drives attached at the moment.

I have sfs on my hardrives and whatever the ram disk uses.

The crashes have gone though ....

@samo79

The space bar is your friend.....

@orgin

have upgraded an all seems fine now.

@orgin

Yes, I'm getting GR's too. Very consitantly in ram-handler

Just in case it's a seperate issue here how to get it (on my system at least)

Double click on workbench to open filer.

Select Ram Disk: from volumes list.

Return to Volumes list. select any other drive / assign, ram-handler will GR. Occasionally ram-handler survives until you slect a directory or file in that volume.

If however you open a second lister and select a file / volume or whatever no GR happens, until you close or navigate away from Ram: in the first lister.

I confidently over wrote my previously insatallation, (that'll teach me) is the previous version still available to download?

@Kicko

It's really annoying! Spoofing in AWeb makes no difference, can you spoof a different browser in OWB? At least in OWB you can usually see the link to go back to the main myspace site (although occasionally it doesn't appear)

@gurus2000

I see a problem similar to that occasionaly when trying to scroll along myspace page before it's finished loading. I find that tweak the OWB window size clears the problem.

Speaking of myspace. does anyone else always find them selves being redirecting to the myspace mobile login page when using OWB? (or AWeb for that matter).

@xenic

No issues with amigans with AWeb.

@orgin

ooops, added now

@orgin

This is what I'm using

<key>Filer.def.dstbackground2pen.r</key>
<string>0xEEEDEEED</string>
<key>Filer.def.dstbackground2pen.g</key>
<string>0xE8B7E8B7</string>
<key>Filer.def.dstbackground2pen.b</key>
<string>0xE6EDE6ED</string>
<key>Filer.def.dstbackground1pen.r</key>
<string>0xFFFFFFFF</string>
<key>Filer.def.dstbackground1pen.g</key>
<string>0xE523E523</string>
<key>Filer.def.dstbackground1pen.b</key>
<string>0xCDDACDDA</string>
<key>Filer.def.devicepen.r</key>
<string>0x59365936</string>
<key>Filer.def.devicepen.g</key>
<string>0x1CDC1CDC</string>
<key>Filer.def.devicepen.b</key>
<string>0x1CDC1CDC</string>
<key>Filer.def.assignpen.r</key>
<string>0x5D175D17</string>
<key>Filer.def.assignpen.g</key>
<string>0x5A045A04</string>
<key>Filer.def.assignpen.b</key>
<string>0x26532653</string>

Makes the destination quite clear with a redish / orange tinge.

[edit] added missing string [/edit]

@orgin

Oh Okay. Should have read that before asking the question in the other thread ....

@orgin

Interesting spec, did you have a use in mind?

@LiveForIt

[quite]
You don't need that old CD it's old and outdated, and comments documentations are most likely wrong or misleading, just download the OS4 SDK from Hyperion, thats all you need.
[/quite]

Actualy I disagree, I refer to quite often, yes the autodocs / include etc are out of date, but the library manuals and other info still have relevence. You need to use both.

@orgin

I keep forgeting to mention this, but can there be an 'act on icon' option?

Currently if you rename a file it icon sats with the old name, if you delete it the icon remains, (that's what reminded me, seeing an icon in a workbench window for a directory I though I'd deleted )

It would be nice to have an option to duplicate the action on the icon, with appropriate adjustments.

rename foo to bar -> foo.info becomes bar.info
duplicate foo and you duplicate foo.info appropriatly renamed.
delete foo also delete foo.info
copy etc etc

It needs to be an option as there are times when you don't want this behaviour. Also the reverse behaviour should not occur, ie manipulating an icon directly should not affect the associated file.

It might even be useful for it to be switchable on a per lister basis, but maybe that's over complicating things.

@xenic

Thanks, despite having looked at that page, I didn't spot the link at the top, doh!

@thread

Drive is currently still behaving itself at UDMA 3

@xenic

I think 512 block for sfs is the optimum value, not the compulsory one. That is other block sizes will work but less efficiently. Ideally you wouldn't set up a partition inefficiently but there no need to worry if you did by accident.

@thomas

Yes, I'm using an 80 wire cable. I tried reduceing the udma last night, and when I got it down to UDMA 3 mplayer could safely stream a five minute video. I'll have to do some more tesing but that may be the solution.

The drive is rated at UDMA 6, so it's a shame if I have to lose a big chunk of it's performance. My two other drives are arated at UDMA 5 and UDMA 4 and both work at full speed. Different makes though (Seagate and IBM respectivley)

How does the bandwidth of the PCI slot affect this?

@broadblues

I've tried changeing filesystem to SFS2 and then to JXFS and in both cases when copy a large amount files / data, ie the entire contents of my work: partition, ie eventually get an error like one shown above. (preceded by an apparent system freeze)

If I try to play a video from the partition with mplayer, then after a short while it locks up, and then produces the above error again.

I just tried with IRQ off for thr drive, and mplayer could stream the video, but audio was crackly. Any one else got one of these western digital drives? What settings are you using with them? It's possible it may be a faulty drive i supose, or could it be a driver bug of some kind?

@nubechecorre


"GParted is the Gnome Partition Editor application"

So linux I think.

@Slayer

I have OS4.1 allready.

I may try sfs 2 as it certainly isn't working properly with sfs 1.

BTW my version of sfs comes out a 1.282 not 1.283

It mounts more constantly at boot time now I've introduced a delay, but it locks after a while when streaming a video with mplayer.

@xenic

Where are those sfs docs you refered too?

@xenic

Yes, block size is 512 (although I have a partition on my old drive with a block size of 1024 with sfs and it works fine...)

The partition give the problems was below the 128 G mark.

It seems to have settled down at the moment, I fiddled arround with UBOOT settings eventually leaving sii0680_timeout at 15 (previosly was 5) and the errors occur much less often, Might be worth playing arround with other filesystems, but the advantage of sfs 1 is it can be read from linux if need be.