GitLab

ftello() returns 0 after fnopen(..., O_APPEND). Use filelength() instead.

For the following log files:
  hungup.log
  error.log
  crash.log
  hack.log
  spam.log
  guru.log

... they can be limited in size, in bytes, by the sysop, along with a maximum retention limit (number of *.#.log files). Configured in SCFG->System->Advanced.

By default, the limit and keep numbers are 0, so "unlimited" (same behavior as before). Once sufficiently tested, I'll change the default in a stock main.cnf file to use a sensible limit (e.g. 10 log files of 10MB each, something like that).

The goal of this commit is that: only modules that either are part-of sbbs.dll/libsbbs.so or need to link with/use that library, will #include "sbbs.h" and thus be dependent on its subsequent includes (e.g. cryptlib.h, jsapi.h). This should mean extdeps.mk can be trimmed way down.

I also removed CVS keyword/comments and trimmed up the boilerplate copyright notice in modified and added source/header files in this commit.

There is no functional change in behavior in this comment.

Thanks to Wilfred van Velzen (2:280/464) for the tip. CopyFile() reduced
the 1GB file copy test (from and to CIFS/SMB) duration from 37 seconds
to 5 seconds with very low CPU utilization!
Created a wrapper for non-Windows OSes in xpdev/dirwrap. This is where
non-Windows-OS-specific optimized versions may appear in the future,
but for now it's just the previous fcopy() implementation (using a 256KB
stack buffer). sbbs doesn't actually copy files very often, so this
isn't as big of a deal as one might assume. The JavaScript global
method: file_copy() also benefits from these improvements, so any
scripts that use it (e.g. tickit.js) will also benefit. binkit.js has
its own file-copy logic (using a 2MB buffer), so no change there.

Using a 256KB read buffer for copying files (rather than one byte at a time).
Apparently calling fread() is not the same as a bunch of calls to fgetc()
after all. Or maybe it was the many calls to fputc() being replaced with
fwrite(). Or maybe it was both. Anyway, decreased the time to copy a 1GB
file from and to a Samba share over a Gb Ethernet network from 13 minutes
to less than a minute. This matters when sbbs is backing up your data/mail
base and the files are big. The mail base is locked while being backed up
and the longer it takes to back up, the longer the mail base is locked and
no mail can be received, read or sent during that time.

CPU utilization to get a large file copy completed quicker.

can be more easily used by more utilities (e.g. echocfg).

enables read & write permissions for user & group & others.

stamps to UTC instead of local time: passing a struct utimbuf fixes it.

(doh!)
This explains why some sysops don't see SCFG save-changes forcing an sbbsctrl
config reload (it wasn't updating the timestamp of ctrl/recycle if the file
already existed).

mutex files).

was specified.

in the access mask. This problem was evident in the FTP server not allowing
simultaneous downloads of the same file.

mounted shared (now why is this different than NFS or local file systems?
and why is it different than smbfs mounted shares on Linux?).

with global JS function (file_mutex).

Updated nopen() and fnopen() prototypes to take const char* for filename.

Get rid of startup.h kludge but makeing YIELD() an empty macro in nopen and
getuserdat