Custom Query (69 matches)
Results (34 - 36 of 69)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #33 | fixed | Review and update documentation for 0.10 GA | ||
| Description |
Just a tracking ticket for me. I'll review these shortly and update as necessary to get ready for packaging. |
|||
| #8 | invalid | Rexx script filled with all zeroes and chkdsk errors. | ||
| Description |
Problem with a Rexx script on a FAT32 volume. After a number of cycles of updating and execution a Rexx script the script file was 'suddenly' completely filled with hex zeroes. For editing of this type of files I usually use Tim Baldwin's T2 editor (now called Tedit) which never failed on me. I experienced the problem for the first time after I migrated to Fat32.ifs 0.9.13, but when I went back to 0.9.12 (of the eCS 2.0 RC5 CD) it appeared again. I must say that I seldomly use a FAT32 volume to directy edit and execute Rexx scripts. So the cause of the problem may have been there all the time but I never hit it. After I moved the file to a JFS volume where it did not appear anymore. During xcopy (/H/O/T/S/E/R/V) of the directory with the all-zero Rexx script xcopy terminated on this file. Chkdsk /F reported lost clusters and recoverd three files (each the size of the allocation uniut: 32K), and in each I found back the origical Rexx script. Although it occurred three times I'm not sure if I can reproduce the problem. But even if I can what does it prove? I suspect Fat32.ifs is the failing component, but how can be sure? Which other relevant information could be collected? Since I have a work-around (moving the file to a JFS volume) I have marked it as 'minor' priority. Regards, Rob. |
|||
| #39 | fixed | SIGSEGV/SIGTERM/SIGBREAK Signals are not caught | ||
| Description |
I have signals handler set up for some cleanup procedures in FORMAT/SYS/CHKDSK, like remounting the disk, but if I interrupt CHKDSK by Ctrl-Break, I see ^C External process cancelled by a Ctrl+Break or another process This is when running from UFAT32.DLL. But if I run the standalone version of CHKDSK, I get: Signal 4 was received and it cleanly remounts disk. In UFAT32.DLL case, we have disk in intermediary state (mounted in MOUNT_ACCEPT mode). The cause, as I suspect, is that CHKDSK is a 32-bit program and sets up 32-bit exception handler, but CHKDSK routine is a 16-bit wrapper around a 32-bit "chkdsk" routine. So, we indeed run 16-bit routine, but an exception handler is 32-bit. This seems to be inconsistent, and thus, the 32-bit exception handler doesn't activate. So, we need a solution for this problem. |
|||
