旼컴컴컴컴컴컴컴컴컴� � � � � � � � � � � � � � 靈캠 � � � � � � � � � � UpLoadProcessor Frequently Asked Questions � 聃컴� � 봬캭 � � � � � � 읕컴컴컴컴컴컴컴컴컴� � 袴袴袴袴袴袴袴袴袴袴� The following are a list of the most commonly asked questions/problems garnered through the support echoes over the years. If you're having a problem, check here first. Table of contents: 1 ULP/ULPSM refuse to run after drive letter/system changes 2 Switching from DOS to OS/2 version 3 Node Work Directory not empty - decremented 4 InfoZip unzip error #50 5 Long Filenames 6 Node number of -1 7 Duplicates and filenames 8 Password problems with RAR 9 Database Validation fails 10 Missing Templates 11 No Mouse Support - Help Buttons 12 JPG not detected even though it's valid 13 -AV's get recompressed /*===========================================================================*/ { 1 ULP/ULPSM refuse to run after drive letter/system changes } (this is two questions, but with the same answer) > I changed my hard disk's partitioning so that it had less drives an now > ULP and ULPSM refuse to run saying unable to open log file. What gives? > I moved ULP to another system and now I can't edit the config with ULPSM. > How do I get it running so I can change the directories! The problem in both cases is that these entries (ULPSM - A. General) Archive work subdirectory D:\ZTTECH\ULP2\WORK\ Disk logfile D:\ZTTECH\ULP2\ULP.LOG are no longer valid. Unable to create the work directory, and open the log file, ULPSM aborts. To prevent this beforehand, go in and change the paths to . which will point to the current directory. THEN move/make changes. Afterwards, go back in and make the changes to point to the new directories. If the damage has already been done and you've made the changes, you have one of 2 options: 1) Recreate your CFG from scratch - less desirable. 2) If the problem is due to a now non-existant drive letter, you can create a one or more RAM Disks so that the old drive letter is available again. recreate the directories, and ULPSM should again run. Immediately go in and change your directories so they point to valid directories and save the changes and exit. You can then remove the RAM drives. /*===========================================================================*/ { 2 Switching from DOS to OS/2 version } > How do I switch from the DOS version of ULP to the OS/2 version of ULP > without losing all my settings and such? Before anything I'd recommend running ULP in Batch mode to finish any testing that needs done, then ULPSM to sort your database. Gather all the OS/2 versions of the various archivers/file testers you want to run. If one or more is unsupported and you still want to run the DOS version of these, you will also need a program called PipeDos to run these with. Now you're ready to switch: First, BACKUP! In an OS/2 window, run ULPSM2 on your current config file. Go through and verify each setting. Make the necessary changes to the archivers/file testers entries (for any where you're not sure of the commandlines, hit F1 for help). After making the changes, exit ULPSM2 and save the changes. Run "ULPSM2 -cYourUlp.CFG -i" to re-initialize the process data file (not necessary but it help as an added precaution and doesn't take that long. In your PCBoard directory, rename PCBTEST.BAT to PCBTEST.CMD and edit it to call ULP2.EXE instead of ULP.EXE If any of your events that call ULP/ULPSM, you will need to move them to an OS/2 event and edit them to call their OS/2 versions. That should complete the switch with all of your data intact! (Note: the same process can be used to switch from OS/2 to DOS) /*===========================================================================*/ { 3 Node Work Directory not empty - decremented } >> Am having problems with ULP reporting the following... >> >> Node Work subdirectory not empty/available...decremented >> >> I have checked the work directory, which is K:\ULP\WORK, and found >> nothing in it. It says it decremented...to what? What should I look >> for. It indicates a node collision in attempting to create node-specific files on startup. When this happens, it logs the problem and adjusts the node number until it can run safely without stomping on the other files. This is caused by one of two problems: running ULP in two different windows and/or workstations with the same node number or trash in the work subdirectory. Usually it's the latter, but it can't hurt to check your system for accidental node duplication. Try removing your work subdirectory and let ULP recreate it, and see if that solves your problem. /*===========================================================================*/ { 4 InfoZip unzip error #50 } >> I'm getting some trouble with InfoZIP, too. Sometimes it gives me an error >> errorlevel 50! I can't find the problem for that, but it happens only a >> few times. [OS/2 versions] Try turning off the "run in window flag" for the ZIP archiver. I've found that InfoZIP's UNZIP sometimes gives an errorlevel 50 due to the stdout I/O redirection thread. /*===========================================================================*/ { 5 Long Filenames } >> I'm running PCB under Dos. So when someone uploads a program programmed >> for Win95 [or OS/2, Unix] with long file names then I can still use the >> regular pkzip right? Yes, but not exactly. Under DOS, PKUNZIP will spit out a warning and skip unpacking a file that won't fit under DOS filename constraints. ULP will stop processing the file at that point to prevent destruction of the archive. Any person writing Windows 95 software should know this and take appropriate steps to keep his filenames within the FAT filename limits, otherwise he risks trashing of his archives by the thousands of BBSs out there that are running under DOS. Note that if you run the OS/2 version of ULP under OS/2 on HPFS drives, this will not be an issue as the long filenames will be processed properly and retained without error. /*===========================================================================*/ { 6 Node number of -1 } >> I finally got around to setting ULP up and have 2.10 sucessfully >> working except for one point. Below is a log entry... >> >> ULP 2.10 Session: 12-29-95 20:23:45 쳐컴컴컴컴컴컴컴컴컴컴컴컴캑 OS: DOS v >> *** WARNING : Node work subdirectory not empty/available...decremented >> Upload Processing Mode >> Matched to upload directory set 1 >> Slow mode enabled...running on node -1 >> [ ... ] >> The work directory setup in ULPSM is K:\ULP\ULPWORK and the data directory >> K:\ULP\ULPDATA. There are NO files in these directories, when I look at them >> I have tried several things including erasing the subdirectories and having >> ULP create them, which it does handily. But I still get this error on every >> file processed. The only way I can think of that can cause this to occur on every file is by feeding a node number of 0 to ULP, either on the command line or via the drop file (PCBOARD.SYS or DOOR.SYS). Node 0 is not a valid node number, either to ULP or PCBoard (at least not according to their manual). /*===========================================================================*/ { 7 Duplicates and filenames } >>-> Every time I see a duplication report the same question pops immediately >>-> in my mind. "What was the name of the other file involved?" >> I've wondered the same thing. But, I'd guess that the database has CRC val >> as opposed to file names. I could be wrong, but why store the name. Especi >> if the file has be renamed. I'd imagine that it would be caught too based >> the CRC. Make sense? ULP stores only mathematical data in the database that represents the file; it does not know either the name of the file or the archive from which it came. To do that would require a minimum tripling of the database size and the incremental speed penalty of manipulating that extra data. However, ZDCS *does* have the ability you desire and ULP has hooks built-in for ZDCS. /*===========================================================================*/ { 8 Password problems with RAR } >> Today I installed the new ULP v2.10. It's working fine for me except >> for one thing. When a user uploads a RAR-packed archive which is >> password-protected, RAR (and thus ULP) waits for the password to be >> entered and waits till sysop-intervention is made. This could be very >> annoying for those who check the new uploads during a nightly event. It's not a bug in ULP...the problem is with RAR. There is no way to disable or override the password question; RAR's author should not make the assumption that someone is around to answer RAR's questions. For example, PKUNZIP exits with an error if it encounters a password protected archive without specifying the -S command switch. That being said, I've found a workaround: add "-p." to your RAR unpacking command line. This will feed a fake password to RAR (a period), forcing it to try and unpack it, ultimately failing. At least it won't stop and ask a dumb question (be sure you have "-y" on the command line as well). /*===========================================================================*/ { 9 Database Validation fails } >> The other thing is there an errorlevel returned when the dup database >> validation fails? I can only tell that it returns a 0 from the log >> file. The reason I ask is that I do a compile as an event and I am >> unable to tell if I need to delete the .IDX file if there is a problem. >> Would it be easier just to delete the .IDX file before running the even >> in any case? Not recommended. If the validation fails, the database is most likely mangled. I've yet to see an instance of a defective index, so if you simply bypass the validation failure and recompile anyway, well...GIGO. >> About the duplicate database. If I delete the index after it fails it >> will recompile without any problems. Yes, it will...all the validation data is in the index, so ULPSM just blindly compiles the raw database when the index is missing, incorporating and assuming valid any crap within. If ULPSM reports the database is corrupt, there's only a 1 in 4 billion chance it's wrong. /*===========================================================================*/ { 10 Missing Templates } >> Is there a reason the hispeed and lospeed templates were dropped from >> the distribution file? I didn't notice it until I saw they were version >> 2.0. They are not (and never have been) in the distribution archive, at least not in the usual sense. They are automatically created when ULP is first installed by running ULPSM with a new configuration filename. If you want to change the version number in the templates, just do it the old- fashioned way: use a text editor. Or use the @VERSION@ macro instead which will always reflect the current version in the templates. /*===========================================================================*/ { 11 No Mouse Support - Help Buttons } >> On this [help] screen, under desqview, with no mouse >> [ ...screen snipped... ] >> How do I access the buttons at the bottom, eg Index ? Alt-I. Also, the "Prev" button is accessed through the Alt-F1 key combination and "Quit" is the same as pressing ESC. /*===========================================================================*/ { 12 JPG not detected even though it's valid } >> Also, the JPEG detection seems to be muffed up. I have 1 JPG file that came >> through the LORD-FDN (the only JPG I've had come in anywhere) and ULP says >> it's an "Unknown" format. Yet the JPEG viewer I have reads/displays it fine You probably have the image parameters for JPEG set to 0x0x0. That disables JPEG detection (same with GIF). At least one of the image values must be non-zero in order for it to be identified and processed. Try 0x0x1 and see what happens (that setting will pass any JPEG it encounters). /*===========================================================================*/ { 13 -AV's get recompressed } >> ZIPs with -AV get re-compressed during processing. Also, ARJ self- >> extractors with security envelopes get re-compressed as well. Note that for a -AV protected archive to be considered valid, *all* files within the archive must have an -AV stamp. If even one file is missing the stamp, the archive will not be considered protected and will be repacked to eradicate evidence of the stamp. This is done to prevent tampering where a file or two is added or replaced and still considered protected by the author's original -AV. Generally, if a BBS ad is added to a -AV protected archive, it will be repacked by ULP since the ad is not stamped. As for ARJ self-extracting archives, ULP can't detect security envelopes in ARJ SFX files. There's no documented or simple means of finding the global header short of searching byte by byte. I may implement it in a future version if it can be done without impacting the archive scanning speed.