I just noticed since I upgraded to 3.16c, I can no longer view the contents of my zip files. The onlu thing I have really modified since the upgrade was the default.src/bin, and I've compared the orig i was using to the new file, and both look the same in the file area. Whats a good place to start looking for the cause. I'm sure it's something stupid I've done, but I can't seem to locate any problems. Thanks in advance.
In SCFG, there's a section where you can configure viewable file types, with the command-lines for viewing files. That might be a good place to start looking. By default though, Synchronet uses the info-zip tool to view zip files, and I believe the stock Synchronet includes info-zip's zip (and unzip) tool. It would be good to double-check to make sure zip & unzip are still in the same directory where they should be (or at least somewhere in your system path). For Windows, I recall seeing them in the sbbs\exec directory.
Re: File View
By: Nightfox to DesotoFireflite on Tue Nov 03 2015 11:51 am
In SCFG, there's a section where you can configure viewable file types, with the command-lines for viewing files. That might be a good place to start looking. By default though, Synchronet uses the info-zip tool to view zip files, and I believe the stock Synchronet includes info-zip's zip (and unzip) tool. It would be good to double-check to make sure zip & unzip are still in the same directory where they should be (or at least somewhere in your system path). For Windows, I recall seeing them in the sbbs\exec directory.
Already did that, and that seems to be fine, and both are in the path. this just happened in the last 2 weeks. It's strange. Thanks
In SCFG, there's a section where you can configure viewable file
types, with the command-lines for viewing files. That might be a
good place to start looking. By default though, Synchronet uses
the info-zip tool to view zip files, and I believe the stock
Synchronet includes info-zip's zip (and unzip) tool. It would be
good to double-check to make sure zip & unzip are still in the
same directory where they should be (or at least somewhere in your
system path). For Windows, I recall seeing them in the sbbs\exec
directory.
Already did that, and that seems to be fine, and both are in the path.
this just happened in the last 2 weeks. It's strange. Thanks
And what do you have set in SCFG->File Options->Viewable File Types->ZIP?
Are you getting an error message?
Re: File View
By: Digital Man to DesotoFireflite on Tue Nov 03 2015 05:20 pm
In SCFG, there's a section where you can configure viewable file Ni>> types, with the command-lines for viewing files. That might be a Ni>> good place to start looking. By default though, Synchronet uses
the info-zip tool to view zip files, and I believe the stock
Synchronet includes info-zip's zip (and unzip) tool. It would be Ni>> good to double-check to make sure zip & unzip are still in the
same directory where they should be (or at least somewhere in your Ni>> system path). For Windows, I recall seeing them in the sbbs\exec Ni>> directory.
Already did that, and that seems to be fine, and both are in the path.
this just happened in the last 2 weeks. It's strange. Thanks
And what do you have set in SCFG->File Options->Viewable File Types->ZIP?
%@unzip -vq %s
Are you getting an error message?
No error message, nothing in the log that I can see. I have both zip and unzip in the sbbs\exec directory, and it's in my path. Just for grins and giggles, I copied both to my sbbs\utils directory last night, which is also in my path, and still not viewable. I've also rebooted several time just in case something was going on with the Win 7 operating system. This seems to be the only issue since upgrade to 3.16c final from 3.16a beta 2 weeks ago.
The default is "%@unzip%. -vq %s". That shouldn't make any difference unless you happen to have just "unzip" in your exec directory (with no .exe extension) in addition to unzip.exe. But you may want to try changing the setting anyway.
Do you have any other external programs configured in SCFG which use "intercept I/O" set to "Standard" and if so, are they working?
The default is "%@unzip%. -vq %s". That shouldn't make any difference unless you happen to have just "unzip" in your exec directory (with no .exe extension) in addition to unzip.exe. But you may want to try changing the setting anyway.
Re: File View
By: Digital Man to DesotoFireflite on Wed Nov 04 2015 03:27 am
The default is "%@unzip%. -vq %s". That shouldn't make any difference unless you happen to have just "unzip" in your exec directory (with no .exe extension) in addition to unzip.exe. But you may want to try changing the setting anyway.
I changed it to what you said, and still doesn't work. Here is a snippet from the log.
11/4 09:07:10a Node 2 Executing external: c:\SBBS\exec\unzip.exe -vq c:\SBBS\data\dirs\newuser\VALPAPER.ZIP
Do you have any other external programs configured in SCFG which use "intercept I/O" set to "Standard" and if so, are they working?
I'm not seeing any other problems, all doors and mods are working fine,
actually, the system is running the best it has ever run lately. No complaints except file viewing. Is there anything I could have done to the default.src/bin file when I changed a prompt in the main section, that would cause this. That's really the only thing i've done since the upgrade. Thanks
Re: File View
By: Digital Man to DesotoFireflite on Wed Nov 04 2015 03:27 am
The default is "%@unzip%. -vq %s". That shouldn't make any difference unless you happen to have just "unzip" in your exec directory (with no .exe extension) in addition to unzip.exe. But you may want to try changing the setting anyway.
11/4 09:07:10a Node 2 Executing external: c:\SBBS\exec\unzip.exe -vq c:\SBBS\data\dirs\newuser\VALPAPER.ZIP
Update, I opened a dos window, and exicuted the same command, and I could view the file ok. So the unzip file is intact and not corrupt.
I hope this gives some kind of clue as to what may be going on. Thanks, as always Rob
Re: File View
By: DesotoFireflite to Digital Man on Wed Nov 04 2015 09:20 am
Do you have "unzip" listed in your SCFG->External Programs->Native Program List?
11/4 09:07:10a Node 2 Executing external: c:\SBBS\exec\unzip.exe -vq
c:\SBBS\data\dirs\newuser\VALPAPER.ZIP
Update, I opened a dos window, and exicuted the same command, and I
could view the file ok. So the unzip file is intact and not corrupt.
I hope this gives some kind of clue as to what may be going on.
Thanks, as always Rob
Windows 10??
Do you have "unzip" listed in your SCFG->External Programs->Native
Program List?
That was it Rob, Actually, nothing was listed in the Native Program list.
11/4 09:07:10a Node 2 Executing external: c:\SBBS\exec\unzip.exe -vq c:\SBBS\data\dirs\newuser\VALPAPER.ZIP
Update, I opened a dos window, and exicuted the same command, and I could view the file ok. So the unzip file is intact and not corrupt.
I hope this gives some kind of clue as to what may be going on. Thanks, as always Rob
Re: File View
By: Digital Man to DesotoFireflite on Wed Nov 04 2015 10:53 pm
Re: File View
By: DesotoFireflite to Digital Man on Wed Nov 04 2015 09:20 am
Do you have "unzip" listed in your SCFG->External Programs->Native Program List?
That was it Rob, Actually, nothing was listed in the Native Program list. I added Unzip.exe, and Zip.exe, and all works fine now. Is there anything else that need to go in that list?
Thank You so much for working with me on
this. I've gotten used to upgrades wiping out my "Global Hot Key Events", but I never thought about checking the "Native Program List"... Again, Thank You So Much:)
It sounded like it was working for you before you upgraded though? If you didn't change your view configuration for zip files, unzip should have been in your native program list already.
How are you upgrading? Upgrades should not "wipe" any configuration settings, so that would definitely be unexpected.
Re: File View
By: Digital Man to DesotoFireflite on Thu Nov 05 2015 10:26 am
How are you upgrading? Upgrades should not "wipe" any configuration settings, so that would definitely be unexpected.
I usually copy the exe and js files from the download to the exec dir, and exec\load dir for the ones that go there, nothing more. the js files that I have modified are in my mods dir, so i don't worry about them being overwritten.
How are you upgrading? Upgrades should not "wipe" any
configuration settings, so that would definitely be unexpected.
I usually copy the exe and js files from the download to the exec dir,
and exec\load dir for the ones that go there, nothing more. the js
files that I have modified are in my mods dir, so i don't worry about
them being overwritten.
None of that would "wipe" any configuration settings. When you say "from the download", what download is that?
Re: File View
By: Digital Man to DesotoFireflite on Thu Nov 05 2015 02:50 pm
How are you upgrading? Upgrades should not "wipe" any
configuration settings, so that would definitely be unexpected.
I usually copy the exe and js files from the download to the exec dir,
and exec\load dir for the ones that go there, nothing more. the js
files that I have modified are in my mods dir, so i don't worry about
them being overwritten.
None of that would "wipe" any configuration settings. When you say "from the download", what download is that?
The nightly builds usually.
With the 3.16c update, I followed the instructions included in the file.
I'm not touching the nightly builds for
3.17 till you say it's safe again, as you warned us not to. I wouldn't think that the way I do it would wipe out any config settings, but just the same, it happens every time to my global ctrl keys. This is the first time ever I have had a problem with the native programs part.
Can you be more specific? Like exactly what file are you extracting and copying from? If the file doesn't contain an xtrn.cnf file, I can't see how that could cause the problem you're describing.
With the 3.16c update, I followed the instructions included in the
file.
sbup316c.zip? It doesn't cause the problem you're describing.
I'm not touching the nightly builds for
3.17 till you say it's safe again, as you warned us not to. I wouldn't
think that the way I do it would wipe out any config settings, but
just the same, it happens every time to my global ctrl keys. This is
the first time ever I have had a problem with the native programs
part.
I suspect something else is going on. Both of those settings are stored in your ctrl/xtrn.cnf file. Are you running something that might be modifying that file? I know there are some JS experiments that have been written that modify the xtrn.cnf (e.g. to synchronize externals between BBSes or auto-import settings) - and it's certainly possible something like that could be corrupting the file. Do you have modules in your BBS that might be modifying that file?
I don't think any Synchronet upgrade has anything to do with this problem, but we should find the cause so it can be fixed.
I suspect something else is going on. Both of those settings are stored in your ctrl/xtrn.cnf file. Are you running something that might be modifying that file? I know there are some JS experiments that have been written that modify the xtrn.cnf (e.g. to synchronize externals between BBSes or auto-import settings) - and it's certainly possible something like that could be corrupting the file. Do you have modules in your BBS that might be modifying that file?
I don't think any Synchronet upgrade has anything to do with this problem, but we should find the cause so it can be fixed.
I just don't know, to my knowledge, I have nothing that will affect that file, especially anything i've created. I just associated it with the upgrades due to the fact, thats the only time I see the issue. But, no, I only copy js and exe files when I do a nightly build, and I know the 3.16c didn't contain the cnf file in question. You did give me a thought, so let me contact another bbs that I do interbbsing with, and see if he might have done something in one of the programs that may be causing this.
I'll let you
know what I found. One question though, why would it only affect the global ctrl codes and native program list only, and not any of the door settings or external programs.
Could this happen if I edited the externals by adding
another door, and it not have saved correctly, as I have added a few new games lately.
I'll start checking the global ctrl codes and native program
list every time I add a game or change something from now on, and see if I can find a pattern. You are right, this is very puzzling. I'll keep you in the loop on whatever I find. Thanks Rob.
know the 3.16c didn't contain the cnf file in question. You did give
me a thought, so let me contact another bbs that I do interbbsing
with, and see if he might have done something in one of the programs
that may be causing this.
Interbbsing how, exactly? Can you elaborate? I was thinking along the lines of CoA, which is just the kind of experimental thing I was talking about. I just checked centerofawareness.net and Valhalla Home Services (your BBS) is listed there, so I think that's the most likely cause.
lines of CoA, which is just the kind of experimental thing I was talking
SCFG also automatically saves backups of your various .cnf files in your ctrl directory (e.g. xtrn.0.cnf would be the most recent backup of your xtrn.cnf file). So if the problem was caused by SCFG, you could at least go back and restore a backup of a working xtrn.cnf file. I don't think
(like 99% more likely) to be caused by the CoA scripts. Nothing against those guys, they make great games, but modifying the .cnf files directly (withOUT the assistance of the appropriate C library), was always (in my opinion) a dubious proposition and in general, a "bad idea" {tm}. :-)
My guess is that it's related to the new loadable modules that were added.
seems like keeping up with changes like these are the main issue. (It would be great if we could add/edit/remove xtrn areas, programs, etc. via the built-in JS object model, and be using the appropriate C library by proxy. Message groups, areas, and subs as well. I won't hold my breath, but I'm just sayin'.)
My guess is that it's related to the new loadable modules that were added. I'd have to look at mcmlxxix's cnflib.js, with which I'm not hugely familiar, but it likely needs to be updated to take those into account. If C.G. is using any of the new mail/msg read/scan loadables, then the structure of his xtrn.cnf will probably differ from what cnflib.js expects.
EC, I havn't got any of the new mail/msg read/scan loadables. I'm staying away from 3.17 till it gets a little more stable. I am at 3.16c. This has
been an ongoing issue, but only with the "global ctrl keys", only this time around whatever happend affected the "Native Programs List". As long as we think we know the cause, I'll live with it, till we can figure out a remedy, I'll just be a little more observant. Thanks
Re: File View
By: Digital Man to DesotoFireflite on Fri Nov 06 2015 01:37:43
lines of CoA, which is just the kind of experimental thing I was talking
Yes, we're probably to blame. :D
SCFG also automatically saves backups of your various .cnf files in your ctrl directory (e.g. xtrn.0.cnf would be the most recent backup of your xtrn.cnf file). So if the problem was caused by SCFG, you could at least go back and restore a backup of a working xtrn.cnf file. I don't think
We do the same (via file_backup() in JS) and encourage sysops to make their own regular backups.
(like 99% more likely) to be caused by the CoA scripts. Nothing against those guys, they make great games, but modifying the .cnf files directly (withOUT the assistance of the appropriate C library), was always (in my opinion) a dubious proposition and in general, a "bad idea" {tm}. :-)
My guess is that it's related to the new loadable modules that were added.
I'd have to look at mcmlxxix's cnflib.js, with which I'm not hugely familiar, but it likely needs to be updated to take those into account. If C.G. is using any of the new mail/msg read/scan loadables, then the structure of his xtrn.cnf will probably differ from what cnflib.js expects.
That said, we've been using this for ~2.5 years without problems, so it seems like keeping up with changes like these are the main issue.
(It would
be great if we could add/edit/remove xtrn areas, programs, etc. via the built-in JS object model, and be using the appropriate C library by proxy. Message groups, areas, and subs as well. I won't hold my breath, but I'm just sayin'.)
Re: File View
By: echicken to Digital Man on Fri Nov 06 2015 10:46:33
My guess is that it's related to the new loadable modules that were added.
Actually, now I'm not so sure. Did that change ("Read Mail", "Scan Msgs", "Scan Subs" loadable modules) affect xtrn.cnf at all, or was it limited to main.cnf?
been an ongoing issue, but only with the "global ctrl keys", only
this time around whatever happend affected the "Native Programs
List". As long as we think we know the cause, I'll live with it,
till we can figure out a remedy, I'll just be a little more
observant. Thanks
Well, sorry for the trouble - and we'll want to get it fixed. I'll see if mcmlxxix can look into it, otherwise I'll have to figure out how his cnflib.js does its thing before I can do much about it. (I already do have some guesses as to why this is happening to you, though.)
@MSGID: <5639166C.26480.sync@valhalla.synchro.net>
@REPLY: <56391043.28189.dove_sync@digitaldistortionbbs.com>
Re: File View
By: Nightfox to DesotoFireflite on Tue Nov 03 2015 11:51 am
In SCFG, there's a section where you can configure viewable file types, with the command-lines for viewing files. That might be a good place to start looking. By default though, Synchronet uses the info-zip tool to view zip files, and I believe the stock Synchronet includes info-zip's zip (and unzip) tool. It would be good to double-check to make sure zip & unzip are still in the same directory where they should be (or at least somewhere in your system path). For Windows, I recall seeing them in the sbbs\exec directory.
Already did that, and that seems to be fine, and both are in the path. this just happened in the last 2 weeks. It's strange. Thanks
See Tagline.
... Here On Earth Computers Alway Win Because They Have Inside Information
been an ongoing issue, but only with the "global ctrl keys", only this time around whatever happend affected the "Native Programs List". As lo as we think we know the cause, I'll live with it, till we can figure ou remedy, I'll just be a little more observant. Thanks
Well, sorry for the trouble - and we'll want to get it fixed. I'll see if mcmlxxix can look into it, otherwise I'll have to figure out how his cnflib. does its thing before I can do much about it. (I already do have some guess as to why this is happening to you, though.)
mcmlxxix can look into it, otherwise I'll have to figure out how his cnfl does its thing before I can do much about it. (I already do have some gu as to why this is happening to you, though.)
I've noticed some issues with the global hot keys on my own system, and have tried to locate the issue in the past, but every time I test it (both by adding/removing global hotkeys via scfg, and also via cnflib.js, and reading/writing the cnf file after making changes programmatically) I experience no issues whatsoever, and no loss of data in xtrn.cnf.. the exter program synchronization routine for CoA does not even touch or look at the hotkeys section, so I am at a loss when it comes to locating where the issue taking place.
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 05:46:23 |
| Calls: | 510 |
| Messages: | 220570 |