Date: Tue, 13 Oct 1998 18:07:10 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Endlisnis cc: djgpp AT delorie DOT com Subject: Re: Uninstaller. In-Reply-To: <361BD7AD.81EBE42A@unb.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Wed, 7 Oct 1998, Endlisnis wrote: > What if LFN is disabled? How do I know what filename will change > to? If it is disabled in the environment, just push LFN=y into the environment at the beginning of your program: putenv ("LFN=y"); However, if it is disabled via the Windows Control Panel, or if your program runs in plain DOS mode on a machine where the package being uninstalled was used under Windows, then the bad news are you don't have any way to know what are the short 8+3 aliases of the long file names. The only way is to look for the candidates using findfirst/findnext or readdir and fnmatch, and ask the user. For example, if you need to delete ALongFileName.Extension, look for ALONGF~?.EXT. Note that this is inherently dangerous and unreliable, so it's probably better to detect this situation and abort telling the user to boot into Windows 9X. > How do I know what the short filename equivalents of the long-filenames > in the manifest will be? See above. You can't, not in the general case. There's a library function _lfn_gen_short_fname that might help, but it only works when LFNs are enabled. I could describe the algorithm used by Windows to generate short aliases, but it's my own gleaning from what I saw, I have no official place to confirm my experience, and the specifics depend on the state of NameNumericTail in a tricky way. > How do I know if "NameNumericTail" is enabled or disabled? Create a long file name and look for possible short aliases using the result of _lfn_gen_short_fname as guidelines. Note that a possible complication is that the state of NameNumericTail when the package was unzipped might be different from its state when the uninstaller runs. > The programs runs fine on a machine with long filenames and DJGPP env. > variable set correctly. If DJGPP isn't set, it prompts for the directory > name. The problem with such programs is that when they backfire, they screw the user big time. So IMHO the program should be thoroughly tested on many different machines, and subject to source-level scrutiny by several experienced DJGPP programmers (I don't mean myself!) before it is released. (Assuming of course that it is indeed better than the `rm' trick, which I'm not sure it is.)