AsyncWB no longer asynchronous

[xenic]

While doing some USB file copy testing to confirm a problem in another forum topic, I discovered that ASyncWB no longer appears to be asynchrouous. The whole purpose of the ASyncWB utility is to allow continued use of WorkBench while file copying is in progress. Otherwise, we might just as well use the original builtin Workbench copy function. It isn't that noticeable when doing moderate hard-disk to hard-disk or hard-disk to ram copies, but if you copy a substantial (10MB with lots of files) directory to a FAT formatted USB media WorkBench becomes almost unusable. During the slow copy, clicking on the WorkBench or a WorkBench window causes the pointer to constantly switch between a "Sleep" pointer and a normal pointer. Unless your timing is lucky, double-clicking a drawer icon does nothing. Can someone else try a large copy (10+ MB of multiple files) to a FAT formatted USB stick to confirm that WorkBench is being blocked by the copy process??

[thomasrapp]

Am I right that you selected a lot of files in one window and then dragged the whole lot into the open window of the destination drawer?

If so, I would say it is not the fault of AsyncWB, it does everything correctly. It's rather caused by the AutoUpdateWB feature which tries to keep up to update the contents of the destination window after each copied icon.

If you don't want this to happen, you should close the destination window and drag the files to the icon of the destination drawer. Then WB does not recognise that the destination changes all the time and does not try to update it permanently.

The permanent update is what causes the mouse pointer to change to a stop-watch and back.

[xenic]

No. You've missed my point altogether. If you had tested this the way I described it you would see what I mean. I stated "if you copy a substantial (10MB with lots of files) directory to a FAT formatted USB media"; which means that I am dragging a single large directory to the window of a USB media device like a memory stick. There is only one icon to update; the icon for the drawer being copied and that shouldn't cause a 5 minute window update while the copy is progressing. WorkBench will constantly switch from a "sleep" pointer to a normal pointer and you can't do much of anything (like opening other windows) with WorkBench while the copy is occurring.

[xenic]

Where's the participation here? Personally, I attempt to reproduce other people's bug/problem reports and either confirm or disprove the problem. However, I see a number of reports that have scores of "views" but only a few people (or none) have bothered to confirm or disprove the problems. How are we gong to get things fixed or changed if everybody is a bystander and not a participant. I think multitasking is an important issue on the Amiga and expected that others would either confirm or disprove the contention that big multifile USB copies ruin WorkBench multitasking and are not asynchronous as they should be.

[mechanic]

Where's the participation here?

OK! OK! Geewhiz, can't even take a leak without someone jumping on ya.

I just copied 171+MB of stuff from my Work partition to a 512MB FAT
USB stick using drag & drop both with the USB stick window open and
closed. No problem using workbench during the copy.

Next I tried 15+MB from a CD to USB, all MIDI files, and again no problem
doing things on the workbench. The copy progress bar only slowed down
when I loaded Timberwolf.

I this several times, copying Drawers and selecting all the Icons, no
difference and no problem using WB during the process.

Sam440ep. No SWAP.

What's next, Boss?

[tonyw]

@xenic:

What machine are you testing this on? Details, please.

[xenic]

@xenic:
What machine are you testing this on? Details, please.

My machine is a SAM Flex 800MZ with 1GB memory installed and running OS4.1u3. Since mechanic was unable to reproduce the problem, I did some more testing myself. Some large directory WorkBench copies don't seem to cause the problem or not very much anyway. Finally I decided to test with a directory almost everyone has on their system; the AISS TBImages directory. When I drag TBImages from a hard disk to a FAT formatted USB memory stick the problem occurs, but intermittently. If I start trying to open windows (double clicking volume or drawer icons) and close them while WorkBench is copying the TBImages drawer to a USB memory stick, at times windows don't open or close and at other times window opening/closing works normally. The only think I can say is to try copying the TBImages drawer to a USB memory stick and attempt to constantly open and close windows on WorkBench. If it works normally then it must be my system that has a problem.

I did notice that the 8GB memory stick I was using to test WB copying was 1/3 as fast as my other mem sticks. However, I also tested with a 16GB SFS formatted mem stick and a 2GB FAT formatted mem stick. The problem still occurred but was less noticable because the copy completed so much faster.

[tbreeden]

My machine is a SAM Flex 800MZ with 1GB memory installed and running OS4.1u3. Since mechanic was unable to reproduce the problem, I did some more testing myself. Some large directory WorkBench copies don't seem to cause the problem or not very much anyway. Finally I decided to test with a directory almost everyone has on their system; the AISS TBImages directory. ... the problem occurs, but intermittently.

Same machine environment here, similar results. Dragging the TBImages directory to either a FAT formatted or a SFS formatted USB stick seems to work about the same. Workbench is fairly usable (on other devices) during the copy. Sometimes the copy seems to hang up for 5 or 10 secs during which WB is not responsive, and sometimes a click on a WB icon seems to be missed. Maybe the root of the problem is not AsyncWB.

The real problem with directories like TBImages, with 3000+ files, is that they are almost unmanageable via WB. Opening TBImages with view-by-name does usually complete, but takes 20 to 30 seconds to show anything, during which WB is unusable. And if you make the mistake of opening a directory like that with view-by-icon+all-files, you are sunk. At least I was never able to do that just now - WB and Dock unusable, the Clock Docky stops, eventually the pointer and keyboard seem frozen (I suspect the USB driver is not reacting well to this situation). Waited 20 minutes or so and nothing completed.

With no way to back out or interrupt, it's hit the reset switch. 3500 is a lot of files, but not a ridiculous amount.

Reminds me of what the Novell salesmen would show customers on Microsoft Networking in the early days - select 100 networked files via Windows Explorer and select Delete - come back 20 minutes later and it was still working on them. They'd ask if you really wanted to switch to this server.
Of course, it was Microsoft, so the answer was, "no, but the boss says we have to"

Tom

[mechanic]

@xenic:
Since mechanic was unable to reproduce the problem, I did some more testing myself.

Success ! Well,, was able to reproduce your results by creating a drawer on the USB stick then
copying files to it using WB. Still tinkering.

[mechanic]

The real problem with directories like TBImages, with 3000+ files, is that they are almost unmanageable via WB. Opening TBImages with view-by-name does usually complete, but takes 20 to 30 seconds to show anything, during which WB is unusable.

Tom[/quote]

I agree.

I noticed that besides the Wait_Pointer on-off thing, that the drawer I
created on the USB stick also blinks. This may be because as each file
is copied the drawer is updated for size and contents before the next
file starts copying.

Not sure if anything could be done about it without changing some basic
operation of workbench as a GUI. As files are graphically copied they're
ready to be looked at with WB before the whole copy process is finished.
In other words, if you cancel the copy process, what has already been
copied is there and useable, already accounted for.

Perhaps this issue has gone pretty much unnoticed because most people
tend to use a file program when doing heavier file operations and the
workbench when doing lighter, or single, file operations.

Maybe it can be changed, but I don't see it as any kind of bug.