Custom Query (518 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (16 - 18 of 518)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#23 fixed Unzip directory removed from config if directory not available at initial scan Gregg Young Gregg Young
Description

One other thing that I have noticed is FM2 eliminates the designated unzip directory is the directory is unavailable at the time FM2 scans on opening. (Very annoying when I fail to notice and unzip a large zip file in a directory containing several thousand files) My unzip directory is on a network drive and I start FM2 from a startup folder so even with the xworkplace delays between programs FM2 beats the requester. As a result I have to go in and reenter the unzip directory in the setup. It should leave the directory and if at the point that I try to to unzip something it is still unavailable give an error message.

#24 fixed Repeated hangs with FM2 requiring reboot StevenHL htravis
Description

FM/2 (V3.04 pre7) choked repeatedly on accessing a 600 file 600 gig directory, causing the WPS and system to be unresponsive. Repeatedly, requiring reboots, when CAD handler /TOP could not kill FM/2 or restore the desktop. No Filestar was able to read the same directory. Solution was to copy all files elsewhere, erase the directory and copy the files back.

A JFS problem with broken files? Is there a trace or log I can start to keep?

htravis@…

I have seen some similar freeze here. JSF Volume but much smaller 110 GB.

rbri

Actually, now that Harry has corrected his numbers, your volume is larger. Fm/2 has known issues with very large numbers of files. Basically it runs out of memory. I would prefer to fail gracefully, but I have not been able to recreate the failure here.

Fm/2 contains code that should fail gracefully, but it's clearly not 100%.

What needs to be done is for some of the users that can recreate this failure on demand to work with me to capture some diagnostic data.

Steven

I now am seeing a slightly different hang using the beta 6. It seems to happen when I serially open several files from an archive I am viewing. For example I open the ACPI archive then view the ACPI.doc close it then view ACPISMP.doc close it then try to view any other of the doc files the archive (unzip) window opens and will hang with the window title reading closing unzip. I can't get to CADPOP but if I hit CAD multiple times the machine reboots. Just before the reboot WPS & FM2 unfreeze and start to complete the operation. Unfortunately, this is very intermittent and I haven't been able to create a test case. There is no popup log entry. Thanks

Gregg

I saw this again this morning only this time it occurred when I opened an archive containing one small file. It opened but the system immediately became non responsive. Same result as above. The archive file work fine after the reboot.

I have also noticed that it occurs while I am scrolling with a wheel mouse using the amouse driver. I remember that at one point I was able to scroll off the end of the internal viewer because of the specific call that amouse makes for scrolling. Is it possible this hang is related. Again this is not reproducible but occurs occasionally.

Gregg

#25 fixed Move long scans to secondary threads Gregg Young Gregg Young
Description

The freeze occurred when FM/2 tried to scan a network drive that is setup using the netdrive samba plugin. Normally if it has problems it returns an error 65. However, the system the drive was on had locked up and when fm/2 scanned it the WPS froze and I had to kill FM/2. The only way I could reopen FM/2 was to exclude the 2 drives. After I rebooted the other machine all works fine. The WPS drives object opened without problem it showed the 2 netdrive drives as empty but no freeze occurred. The same error message as below occurred again but I think the message was generated when I tried to kill FM/2 not when the freeze occurred.

Most of the scans that can take a long time are done on separate threads, so this kind of failure will not lock up fm/2. However, there are a few that are still done on the PM thread and this can cause apparent Desktop lockups. If this is the case, pressing Ctrl-Esc several times should cause PM to take control away from fm/2.

If we can identify what fm/2 was trying to do, we should be able to move this logic to a thread.

The trap should not occur, even with slow access. Unfortunately, the trap is not within fm/2 code, so it's hard to analyze without a process dump. I will be adding exceptq support to fm/2, once I get some in-progress exceptq rework completed. This will provide enhanced trap logging, without the need to resort to trap dumps.

The trap appears to somewhere in DOSREADASYNC or DOSWRITEASYNC, but that does not tell us much about where and how fm/2 managed to pass bad arguments to the API.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.