Bugs and suggestions
Although this web site has changed slightly, this page hasn't changed very much, except in colour.
- JF002 - Not verified, 1 reported
Quantum Software's Undelete causes hang while LongFiles is loaded and a file is being deleted;
- RT001 - Not verified, 1 reported
Unlocking a locked machine causes partial lock
- RW002 - Not verified, not repeated, 1 reported
Copying a directory tree fails if a directory in the tree has a long name and Newer is turned on;
Suggestions asked for
- None at the moment! I think I've done them all...
A DOS disc is an image filing system. Image filing systems use different interfaces than normal filing system, which LongFiles cannot interface with. As a result, DOSFS (and other image filing systems) will not work with LongFiles.
- JP001 (fixed in 2.50)
LongFiles now works with the Simtec IDE interface
- SC001 (always been fixed; just needed know-how)
LongFiles can be made to work with CFS - although it is actually the other way around. See the CFS page;
- JT006 (fixed in 2.07)
The front-end now uses Choices$Write instead of Choices$Path - this should fix anyone who was not able to save the settings in version 2.06;
- IR002 (fixed in 2.07)
The top item should now not be a weird filing system name - this was thought to have been 'possibly' fixed in 2.06, but there was another area where the problem occurred;
- IR001 (fixed in 2.06)
LongFiles no longer crashes on boot-up.
- GR001 (fixed in 2.06)
The slow-down seems to have been fixed. Why, I don't know - the only code to be modified in the main module was to do with SP001. Perhaps they were related...;
- MB001 (fixed in 2.06)
Again, I don't know why this was fixed. I did receive a report that it was fixed in 2.05, so it may have possibly been a side-effect of NR001. With both of these bugs, I'll keep an eye on them...;
- SP001 (fixed in 2.06)
*Wipe uses a different mechanism for deleting files - the file number used in OS_GBPB 10 does not start at zero when it finds a file. The fix for this is not nice, and may not work with all programs... It does not affect the desktop.
- NR001 (fixed in 2.05)
The results from OS_GBPB 11 were being corrupted.;
- FP003 (fixed in 2.05)
As suspected, the fix for NR001 also fixes FP003;
- JF001 (fixed in 2.05)
You can now not use wild-cards in long filenames. This was a follow-on from JT003, except that I hadn't put enough wild-cards in the list of those not obtainable. "?" was re-introduced, as it is not a wild-card;
- FP001 (fixed in 2.04)
Front-end claiming 1860K; now reduced to 40K;
- RW001 (fixed in 2.04)
LongFiles was hiding files;
- JT001 (fixed in 2.02)
You can now rename a file to a long filename where a short filename exists whose first 10 characters are the same as the long filenames;
- JT002 (fixed in 2.02)
You can now rename a long filename with different case to listed to another long filename without a zombie entry neing created in the LongFiles table;
- JT003 (fixed in 2.02)
Wild cards "*" and "?" can now not be used in rename. See JF001;
- JT004 (fixed in 2.02)
Errors are now reported properly from filing system;
- JT005 (fixed in 2.02)
"Bad" filing system name is not displayed on front-end's menu;
- JW000 (appended in 2.02)
Converting LongFiles 0.10/0.11 file with zombies does not create zombie entries in LongFiles 2;
- JW000 (fixed in 2.01)
Creation of zombie entries in LongFiles 2 has been eliminated;
- JT000 (fixed in 2.01)
New directories now start with new IDs, rather than the previously searched directory's IDs;
- JF004 (added in 2.06)
There is now a sub-menu off Quit to kill LongFiles as well as the front-end;
- JF003 (added in 2.06)
LongFiles will use Choices: to store the defaults file. It will, however, read the one inside LongFilesif it doesn't exist. This aids upgrading;
- RB001 (added in 2.06)
ATAFS added to the !Help file;
- PN001 (added in 2.05)
!LongFiles can be put in your PreDesk directory without any problems. It will set up your default LongFiles filing systems, as long as you configure it in the PreDesk directory;
- FP002 (added in 2.04)
Front-end icon now configurable on/off;
How the bug system works
If a bug is reported to me, and it is a new bug, then it will be assigned a unique number, based on your initials, and a numeric code. It will be put on this list shortly after you get a reply from me.
If a bug is labelled as "Not verified", then either I have not seen this bug and so have not been able to verify its existience/actions, or I have tried to replicate it and I was unsuccessful in doing so, in which case, it will be labelled "not repeated".
The number of times this bug has been reported is labelled as "(n) Reported", where (n) is the number of times this bug is reported. Note that even if 1,000 people report the same bug, it does not mean that it is verified!
Please note that in order to fix bugs, I will need as much information as to what causes the bug, and if it can be replicated in any way. If it is a one-off bug, then it is very hard to track, but if it happens every time you do 'xyz', then it should be possible to do it on my machine by doing 'xyz'.
If it is some peculiar piece of software which causes problems, then I may need to get hold of that software. If it's freely available, then it would be fairly easy for me to get it. If it costs money, then as I'm not being paid for this, I would be loathed to actually fork out and get it. In this case, I may need some logs from a debug version of LongFiles, or even a very kind software producer :)
If I have already fixed the problem in code that has not been released, the bug is still 'open', but it will be marked as being fixed.