anyone know how i can get the file size in my files list? i can get the name, date and descriptions but i'm not finding anything for the file's size :(

/sbbs/exec/filelist - -- -dfd -hdr -jst -noe /sbbs/data/dirs/newuplds/sestar.lst


)\/(ark

---
þ Synchronet þ The SouthEast Star Mail HUB - SESTAR
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: file size in filelist.txt file?
By: Rampage to All on Tue Aug 06 2019 10:30 pm

anyone know how i can get the file size in my files list? i can get the name, date and descriptions but i'm not finding anything for the file's size :(

/sbbs/exec/filelist - -- -dfd -hdr -jst -noe /sbbs/data/dirs/newuplds/sestar.lst

The credit value is usually the same as the file's size, so the "-cdt" optino should work for you. No?

digital man

This Is Spinal Tap quote #22:
David St. Hubbins: Here lies David St. Hubbins... and why not?
Norco, CA WX: 75.4øF, 59.0% humidity, 7 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: file size in filelist.txt file?
By: Digital Man to Rampage on Tue Aug 06 2019 20:23:26

anyone know how i can get the file size in my files list? i can get the

name, date and descriptions but i'm not finding anything for the file's size :(

/sbbs/exec/filelist - -- -dfd -hdr -jst -noe

/sbbs/data/dirs/newuplds/sestar.lst

The credit value is usually the same as the file's size, so the "-cdt"

optino should work for you. No?

i don't know... i disabled all of that since i don't and never have liked file credits... i'll take a look, though...

i do have to ask, though, how that would work if someone has doubled or halved the credits per byte? but that's probably rhetorical at this point ;)

)\/(ark

---
þ Synchronet þ The SouthEast Star Mail HUB - SESTAR
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Aug 07 07:15:52, Rampage wrote to you:

/sbbs/exec/filelist - -- -dfd -hdr -jst -noe
/sbbs/data/dirs/newuplds/sestar.lst

The credit value is usually the same as the file's size, so the "-cdt"
optino should work for you. No?

i don't know... i disabled all of that since i don't and never have liked file credits... i'll take a look, though...

i did add the -cdt option and i do have something that appears to match the files' sizes on the ones i checked... thanks for the pointer...

now if i can figure out how to get the files' sizes to show in the listings in the BBS files areas ;)

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them. ... Ahh, mother's milk!
---
* Origin: (1:3634/12.73)

Re: file size in filelist.txt file?
By: mark lewis to Digital Man on Fri Aug 09 2019 01:48 pm

On 2019 Aug 07 07:15:52, Rampage wrote to you:

/sbbs/exec/filelist - -- -dfd -hdr -jst -noe
/sbbs/data/dirs/newuplds/sestar.lst

The credit value is usually the same as the file's size, so the "-cdt"
optino should work for you. No?

i don't know... i disabled all of that since i don't and never have liked file credits... i'll take a look, though...

i did add the -cdt option and i do have something that appears to match the files' sizes on the ones i checked... thanks for the pointer...

now if i can figure out how to get the files' sizes to show in the listings in the BBS files areas ;)

They normally show. What are you seeing?

digital man

Synchronet/BBS Terminology Definition #2:
ARS = Access Requirement Strings
Norco, CA WX: 88.0øF, 35.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: file size in filelist.txt file?
By: mark lewis to Digital Man on Fri Aug 09 2019 01:48 pm

On 2019 Aug 07 07:15:52, Rampage wrote to you:

/sbbs/exec/filelist - -- -dfd -hdr -jst -noe
/sbbs/data/dirs/newuplds/sestar.lst

The credit value is usually the same as the file's size, so the "-cdt"
optino should work for you. No?

i don't know... i disabled all of that since i don't and never have liked file credits... i'll take a look, though...

i did add the -cdt option and i do have something that appears to match the files' sizes on the ones i checked... thanks for the pointer...

now if i can figure out how to get the files' sizes to show in the listings in the BBS files areas ;)

They normally show. What are you seeing?

digital man

I've played with that as well, but I didn't see an option to display file sizes :/

/sbbs/exec/filelist

FILELIST v3.15-Win32 (rev 1.20) - Generate Synchronet File Directory Lists

usage: FILELIST <dir_code or - for ALL> [switches] [outfile]

switches: -lib name All directories of specified library
-not code Exclude specific directory
-new days Include only new files in listing (days since upload)
-cat Concatenate to existing outfile
-pad Pad filename with spaces
-hdr Include directory headers
-cdt Include credit value
-tot Include credit totals
-uln Include uploader's name
-uld Include upload date
-dfd Include DOS file date
-dld Include download date
-dls Include total downloads
-nod Exclude normal descriptions
-noe Exclude normal descriptions, if extended exists
-ext Include extended descriptions
-jst Justify extended descriptions under normal
-+ Include extended description indicator (+)
-- Include offline file indicator (-)
-* Short-hand for -pad -hdr -cdt -+ --

I was starting to script a js for that but gave up once the pizza guy showed up at my door :-P


My doctor said I have the body of a 25 year old ... and the mind of a 10 :-/

---
þ Synchronet þ AlleyCat! BBS - http://alleycat.synchro.net:81
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

mark lewis wrote to Digital Man <=-

The credit value is usually the same as the file's size, so the "-cdt"
optino should work for you. No?

i don't know... i disabled all of that since i don't and never have liked file credits... i'll take a look, though...

i did add the -cdt option and i do have something that appears to
match the files' sizes on the ones i checked... thanks for the
pointer...

now if i can figure out how to get the files' sizes to show in
the listings in the BBS files areas ;)

This last part is what I've been describing to you for a long
while now, for files auto-added by Fido FDN areas... It does show
the file sizes now for me, after setting all the FDN file areas to
be "free downloads"... Doesn't make much sense, but there it is.



... All the easy problems have been solved.
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Aug 09 13:10:36, you wrote to me:

i did add the -cdt option and i do have something that appears to
match the files' sizes on the ones i checked... thanks for the
pointer...

now if i can figure out how to get the files' sizes to show in the
listings in the BBS files areas ;)

They normally show. What are you seeing?

here's a couple of examples... this is using the [L]ist command but they all look like this...


4drvu100.zip C 31.3K 4_Drive Utilities v1.0: IDE Inquiry util
for up to 4 hard disk drives. Supports
drives on both Primary and Secondary Port
Addresses. Gives Cyl-Hd-Sector per track,
Multiple Sectors, DMA, LBA and buffer
capabilities. Req: 286+CPU. Dustbowl
Designs, Inc. (Date 7/04/93) -AV
ACER10X .ZIP D 40.5K ATAPI CD-Rom driver for high speed units
ALTER386.ZIP E 8.8K Global search and replace utility, 286 only - by Rob Flor.


i don't know if it matters or not, there's no difference either way, but extended descriptions are turned ON...

what i prefer to see is something like this...


4drvu100.zip C 31.3K 2019/07/04 4_Drive Utilities v1.0: IDE Inquiry util
for up to 4 hard disk drives. Supports
drives on both Primary and Secondary Port
Addresses. Gives Cyl-Hd-Sector per track,
Multiple Sectors, DMA, LBA and buffer
capabilities. Req: 286+CPU. Dustbowl
Designs, Inc. (Date 7/04/93) -AV
ACER10X .ZIP D 40.5K 1996/07/05 ATAPI CD-Rom driver for high speed units ALTER386.ZIP E 8.8K 1998/03/23 Global search and replace utility, 286 only
- by Rob Flor.


yes, four digit years if possible but certainly in YY/MM/DD or YY-MM-DD format if not (yet) possible...

FWIW: my old system had a template field where we would use macros and color codes to lay out our own file listing format... this would be a nice feature for sbbs, too... it would be a move away from the current hard coded(??) format
to one more freeform allowing operators more customization freedoms...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them. ... A New Year's resolution: in one year and out the other.
---
* Origin: (1:3634/12.73)

On 2019 Aug 09 16:36:00, you wrote to me:

now if i can figure out how to get the files' sizes to show in
the listings in the BBS files areas ;)

This last part is what I've been describing to you for a long
while now,

ahhhh!

for files auto-added by Fido FDN areas...

i don't know that it is limited to addfiles imports...

It does show the file sizes now for me, after setting all the FDN file areas to be "free downloads"... Doesn't make much sense, but there it
is.

hummm... so even if the file credits are not used, we still have to set free downloads? i had that at one time but hated seeing "FREE" in blinking red all over the listings...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them. ... Drunk chicks think I'm hot.
---
* Origin: (1:3634/12.73)

mark lewis wrote to Gamgee <=-

now if i can figure out how to get the files' sizes to show in
the listings in the BBS files areas ;)

This last part is what I've been describing to you for a long
while now,

ahhhh!

for files auto-added by Fido FDN areas...

i don't know that it is limited to addfiles imports...

It may not be. I am still not convinced that the root cause of it
is just the missing 'size' definition in a TIC file... I get some
FDN files from othernets that show up properly, and I think it's
because all those TIC files have the size specified in them.

If you think about the command line parameters passed to addfiles
by tickit, which is simply -zd, there's nothing there to give any
clue about file size. Just to use FILE_ID.DIZ if available, and
to delete the tickit-files.bbs file afterwards. That's why my
kludge of making the passed parameters "-szdn" fixed the blinking
FREE problem, because now addfiles *searches* for the *new* file
and gets the size that way.

It does show the file sizes now for me, after setting all the FDN file areas to be "free downloads"... Doesn't make much sense, but there it
is.

hummm... so even if the file credits are not used, we still have
to set free downloads? i had that at one time but hated seeing
"FREE" in blinking red all over the listings...

I'm still confused... I was seeing the blinking red FREE when I
did *NOT* have it set to free downloads. For reasons I don't
completely grasp, setting the areas to be free downloads causes
the file size to show up in the listings rather than the blinking
red FREE...

To summarize my thoughts on this, I think that ALL tic files
should have the size of the associated file specified in them, and
I also think that maybe the parameters passed to addfiles within
tickit could be improved.



... All the easy problems have been solved.
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: file size in filelist.txt file?
By: mark lewis to Digital Man on Sun Aug 11 2019 01:26 pm

On 2019 Aug 09 13:10:36, you wrote to me:

i did add the -cdt option and i do have something that appears to
match the files' sizes on the ones i checked... thanks for the
pointer...

now if i can figure out how to get the files' sizes to show in the
listings in the BBS files areas ;)

They normally show. What are you seeing?

here's a couple of examples... this is using the [L]ist command but they all look like this...

4drvu100.zip C 31.3K 4_Drive Utilities v1.0: IDE Inquiry util
for up to 4 hard disk drives. Supports
drives on both Primary and Secondary Port
Addresses. Gives Cyl-Hd-Sector per track,
Multiple Sectors, DMA, LBA and buffer
capabilities. Req: 286+CPU. Dustbowl
Designs, Inc. (Date 7/04/93) -AV
ACER10X .ZIP D 40.5K ATAPI CD-Rom driver for high speed units
ALTER386.ZIP E 8.8K Global search and replace utility, 286 only - by Rob Flor.

i don't know if it matters or not, there's no difference either way, but extended descriptions are turned ON...

what i prefer to see is something like this...

4drvu100.zip C 31.3K 2019/07/04 4_Drive Utilities v1.0: IDE Inquiry util
for up to 4 hard disk drives. Supports
drives on both Primary and Secondary Port
Addresses. Gives Cyl-Hd-Sector per track,
Multiple Sectors, DMA, LBA and buffer
capabilities. Req: 286+CPU. Dustbowl
Designs, Inc. (Date 7/04/93) -AV
ACER10X .ZIP D 40.5K 1996/07/05 ATAPI CD-Rom driver for high speed units ALTER386.ZIP E 8.8K 1998/03/23 Global search and replace utility, 286 only
- by Rob Flor.

So what you said was
"now if i can figure out how to get the files' sizes to show"

I'm guessing you meant say "now if I can figure out how to get the files' *dates* to show".

Addfiles has an option to include the file date in the description:
-f include file date in descriptions

And each directory in SCFG has this option:

É[þ][?]ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º Include Upload Date in Descriptions º
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
º ³Yes º
º ³No º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Include Upload Date in File Descriptions:

If you wish the upload date of each file in this directory to be
automatically included in the file description, set this option to
Yes.

yes, four digit years if possible but certainly in YY/MM/DD or YY-MM-DD format if not (yet) possible...

FWIW: my old system had a template field where we would use macros and color codes to lay out our own file listing format... this would be a nice feature for sbbs, too... it would be a move away from the current hard coded(??) format to one more freeform allowing operators more customization freedoms...

Synchronet currently only supports 2 date formats for input and short-output: MM/DD/YY and DD/MM/YY.

digital man

This Is Spinal Tap quote #32:
Derek Smalls: [A jog?] We don't have time for that.
Norco, CA WX: 69.2øF, 70.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: file size in filelist.txt file?
By: mark lewis to Gamgee on Sun Aug 11 2019 01:21 pm

On 2019 Aug 09 16:36:00, you wrote to me:

now if i can figure out how to get the files' sizes to show in
the listings in the BBS files areas ;)

This last part is what I've been describing to you for a long
while now,

ahhhh!

for files auto-added by Fido FDN areas...

i don't know that it is limited to addfiles imports...

It does show the file sizes now for me, after setting all the FDN file areas to be "free downloads"... Doesn't make much sense, but there it is.

hummm... so even if the file credits are not used, we still have to set free downloads? i had that at one time but hated seeing "FREE" in blinking red all over the listings...

If a directory is set to "Free" in SCFG, then the file's sizes are shown, not the "Free". "Free" (blinking) is only shown for files that have credit value of
0 (free) in a non-free directory.

digital man

Synchronet "Real Fact" #41:
Synchronet's cross-platform library is called XPDEV (named before Windows XP). Norco, CA WX: 69.2øF, 70.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: file size in filelist.txt file?
By: Digital Man to mark lewis on Sun Aug 11 2019 10:07 pm

Re: file size in filelist.txt file?
By: mark lewis to Digital Man on Sun Aug 11 2019 01:26 pm

On 2019 Aug 09 13:10:36, you wrote to me:

i did add the -cdt option and i do have something that appears to
match the files' sizes on the ones i checked... thanks for the
pointer...

now if i can figure out how to get the files' sizes to show in the
listings in the BBS files areas ;)

They normally show. What are you seeing?

here's a couple of examples... this is using the [L]ist command but they all look like this...

4drvu100.zip C 31.3K 4_Drive Utilities v1.0: IDE Inquiry util
for up to 4 hard disk drives. Supports
drives on both Primary and Secondary Port
Addresses. Gives Cyl-Hd-Sector per track,
Multiple Sectors, DMA, LBA and buffer
capabilities. Req: 286+CPU. Dustbowl
Designs, Inc. (Date 7/04/93) -AV
ACER10X .ZIP D 40.5K ATAPI CD-Rom driver for high speed units ALTER386.ZIP E 8.8K Global search and replace utility, 286 only - by Rob Flor.

i don't know if it matters or not, there's no difference either way, but extended descriptions are turned ON...

what i prefer to see is something like this...

4drvu100.zip C 31.3K 2019/07/04 4_Drive Utilities v1.0: IDE Inquiry util
for up to 4 hard disk drives. Supports
drives on both Primary and Secondary Port
Addresses. Gives Cyl-Hd-Sector per track,
Multiple Sectors, DMA, LBA and buffer
capabilities. Req: 286+CPU. Dustbowl
Designs, Inc. (Date 7/04/93) -AV
ACER10X .ZIP D 40.5K 1996/07/05 ATAPI CD-Rom driver for high speed units ALTER386.ZIP E 8.8K 1998/03/23 Global search and replace utility, 286 only
- by Rob Flor.

So what you said was
"now if i can figure out how to get the files' sizes to show"

I'm guessing you meant say "now if I can figure out how to get the files' *dates* to show".

Addfiles has an option to include the file date in the description:
-f include file date in descriptions

And I just added a -F <fmt> option to addfiles, so you can (hopefully) specify your own desired date/time stamp format, in strftime() syntax.

digital man

Synchronet "Real Fact" #4:
Synchronet version 3 is written mostly in C, with some C++, x86 ASM, and Pascal.
Norco, CA WX: 66.3øF, 78.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Aug 11 19:53:00, you wrote to me:

i don't know that it is limited to addfiles imports...

It may not be. I am still not convinced that the root cause of it
is just the missing 'size' definition in a TIC file... I get some
FDN files from othernets that show up properly, and I think it's
because all those TIC files have the size specified in them.

i dunno... my tickit does specifically check to see if there's a file size and if not, it specifically takes it off the HD and adds it to the TIC and to the addfiles tickit-files.bbs file for importing into the BBS..

If you think about the command line parameters passed to addfiles
by tickit, which is simply -zd, there's nothing there to give any
clue about file size.

it is not needed if the tickit-files.bbs file has it... it should be there if the TIC file has it and writes it to the files.bbs file... i even added the specific position numbers to the addfiles command that tickit executes so it will find them... i think that's what they were...maybe it was date and description? i don't recall right now...

Just to use FILE_ID.DIZ if available, and to delete the
tickit-files.bbs file afterwards. That's why my kludge of making the passed parameters "-szdn" fixed the blinking FREE problem, because now addfiles *searches* for the *new* file and gets the size that way.

that works, too...

It does show the file sizes now for me, after setting all the FDN
file areas to be "free downloads"... Doesn't make much sense, but
there it is.

hummm... so even if the file credits are not used, we still have to
set free downloads? i had that at one time but hated seeing "FREE" in
blinking red all over the listings...

I'm still confused... I was seeing the blinking red FREE when I did
*NOT* have it set to free downloads. For reasons I don't completely grasp, setting the areas to be free downloads causes the file size to
show up in the listings rather than the blinking red FREE...

i have to look but i think all my areas are marked as free downloads...

[time passes]

yup! all of my 300someodd file areas are marked as free downloads...

To summarize my thoughts on this, I think that ALL tic files
should have the size of the associated file specified in them,

the file's size is an /optional/ line in the TIC file spec...

and I also think that maybe the parameters passed to addfiles within tickit could be improved.

possibly but that depends on if the data desired already exists or not... if it
does then it is extra work for no gain...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them. ... We are always getting ready to live but never living.
---
* Origin: (1:3634/12.73)

On 2019 Aug 11 22:07:58, you wrote to me:

ACER10X .ZIP D 40.5K 1996/07/05 ATAPI CD-Rom driver for high speed units
ALTER386.ZIP E 8.8K 1998/03/23 Global search and replace utility, 286
only - by Rob Flor.

So what you said was
"now if i can figure out how to get the files' sizes to show"

I'm guessing you meant say "now if I can figure out how to get the files' *dates* to show".

i did oops there... sorry...

Addfiles has an option to include the file date in the description:
-f include file date in descriptions

And each directory in SCFG has this option:

É[þ][?]ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º Include Upload Date in Descriptions º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
º ³Yes º
º ³No º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Include Upload Date in File Descriptions:

that wording makes me think the date will be in the file's description block instead of in the file's date field in the data record... but it is also the upload date instead of the file's actual date... i don't care about the upload date other than when doing a "new files since" listing... that kinda means there would need to be two date fields in the file records... one for the file and one for the upload...

If you wish the upload date of each file in this directory to be automatically included in the file description, set this option to
Yes.

yeah, not the upload date... the file's actual date... i actually have a routine that goes through the files and ensures their archive date on disk is the same as the date inside the archive...

i'm trying to remember my old setup... we had like 3 or 4 dates associated with
each file... the file's date, the upload date, the last download date and i can't remember the 4th one if there was one... i'm too wiped right now to go rooting through the old docs :/

yes, four digit years if possible but certainly in YY/MM/DD or YY-MM-DD
format if not (yet) possible...

FWIW: my old system had a template field where we would use macros and
color codes to lay out our own file listing format... this would be a
nice feature for sbbs, too... it would be a move away from the current
hard coded(??) format to one more freeform allowing operators more
customization freedoms...

Synchronet currently only supports 2 date formats for input and short-output: MM/DD/YY and DD/MM/YY.

yup... i'm aware... either i or max mentioned a request for YY/MM/DD and/or YYYY/MM/DD some long time back... it may simply have been missed...

i'd also like to see a template for YYYY MMM DD where MMM is the three leter month abbreviation... sometimes those

%a %b %e %Y %T %Z

Tue Aug 13 2019 00:35:00 UTC

strings are just not what i'm looking for... in some of my code, the above is about all i can get from some software so i have to take it as a string and chop it up into the bit i'm after so i can display them the way i want ;)

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them. ... BEEF! 'Cause the west wasn't won on salad.
---
* Origin: (1:3634/12.73)

On 2019 Aug 12 00:05:42, you wrote to me:

And I just added a -F <fmt> option to addfiles, so you can (hopefully) specify your own desired date/time stamp format, in strftime() syntax.

i'll try to give it a test soon-ish...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them. ... CanYouComeHereAndFixMySpaceBarKey?ThankYou!
---
* Origin: (1:3634/12.73)

Re: file size in filelist.txt file?
By: mark lewis to Digital Man on Tue Aug 13 2019 04:41 pm

Addfiles has an option to include the file date in the description:
-f include file date in descriptions

And each directory in SCFG has this option:

É[þ][?]ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º Include Upload Date in Descriptions º ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
º ³Yes º
º ³No º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Include Upload Date in File Descriptions:

that wording makes me think the date will be in the file's description block instead of in the file's date field in the data record...

That's correct. There is "file's date field" in the Synchronet filebase. A file's date/time is best taken from the file system, not a database.

but it is also the
upload date instead of the file's actual date... i don't care about the upload date other than when doing a "new files since" listing... that kinda means there would need to be two date fields in the file records... one for the file and one for the upload...

We do have an "upload date" field, but there's no mode to display *that* date/time in the file listings. I do plan to make the file listing format more flexible in the future. The various dates for a file are displayed when looking
a file's "extended info".

If you wish the upload date of each file in this directory to be automatically included in the file description, set this option to
Yes.

yeah, not the upload date... the file's actual date... i actually have a routine that goes through the files and ensures their archive date on disk is the same as the date inside the archive...

When does that routine happen? If it's some time after the file was uploaded, then having sbbs add it (the file's date/time) to the file's description wouldn't really help ya (they'd be out-of-sync later when your routine ran).

digital man

Synchronet "Real Fact" #19:
The first Synchronet BBS (Vertrauen) went live in July of 1991 (replacing WWIV).
Norco, CA WX: 89.9øF, 39.0% humidity, 8 mph NE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

mark lewis wrote to Gamgee <=-

i don't know that it is limited to addfiles imports...

It may not be. I am still not convinced that the root cause of it
is just the missing 'size' definition in a TIC file... I get some
FDN files from othernets that show up properly, and I think it's
because all those TIC files have the size specified in them.

i dunno... my tickit does specifically check to see if there's a
file size and if not, it specifically takes it off the HD and
adds it to the TIC and to the addfiles tickit-files.bbs file for
importing into the BBS..

Is your Tickit any different than mine? I'm using the stock
version now, latest one. But I'm also a little confused by the
above... I'm talking about the TIC files that I get from you,
none of them has a file size specified in the TIC file. It's not
getting added before it's forwarded on to me, that's for sure.
Therefore when my Tickit processes the incoming, there's no size
to be added to 'tickit-files.bbs'.

If you think about the command line parameters passed to addfiles
by tickit, which is simply -zd, there's nothing there to give any
clue about file size.

it is not needed if the tickit-files.bbs file has it... it should
be there if the TIC file has it and writes it to the files.bbs
file...

Exactly, but the TIC file does *NOT* have it and it doesn't get
written to the tickit-files.bbs file...

i even added the specific position numbers to the
addfiles command that tickit executes so it will find them... i
think that's what they were...maybe it was date and description?
i don't recall right now...

Yes, those are the description offset and size offset, but.... if
there's no size specified that value isn't there.

Just to use FILE_ID.DIZ if available, and to delete the
tickit-files.bbs file afterwards. That's why my kludge of making the passed parameters "-szdn" fixed the blinking FREE problem, because now addfiles *searches* for the *new* file and gets the size that way.

that works, too...

Yes, one side-effect of using that though, is that files that get
replaced by a new one of the same name do not get recognized as a
"new" file, because the name was already in the database.

It does show the file sizes now for me, after setting all the FDN
file areas to be "free downloads"... Doesn't make much sense, but
there it is.

hummm... so even if the file credits are not used, we still have to
set free downloads? i had that at one time but hated seeing "FREE" in
blinking red all over the listings...

I'm still confused... I was seeing the blinking red FREE when I did
*NOT* have it set to free downloads. For reasons I don't completely grasp, setting the areas to be free downloads causes the file size to
show up in the listings rather than the blinking red FREE...

Since I posted the above I've seen a post by DM that clarified the
workings of the free/credit download accounting methods and it
makes more sense to me now.

i have to look but i think all my areas are marked as free
downloads...

[time passes]

yup! all of my 300someodd file areas are marked as free
downloads...

To summarize my thoughts on this, I think that ALL tic files
should have the size of the associated file specified in them,

the file's size is an /optional/ line in the TIC file spec...

I'd like to see that get changed to a /required/ line.

and I also think that maybe the parameters passed to addfiles within tickit could be improved.

possibly but that depends on if the data desired already exists
or not... if it does then it is extra work for no gain...

But if it (the data desired) *DOESN'T* exist...

Now granted, I'm free to modify my copy of tickit.js any way I
want to, and I have, as mentioned above. But it would be nice to
have it work as a default configure, which can't be done if the
incoming TICs don't contain the needed data.

I'm not really bitching about this, just trying to clarify what
I'd like to see, and what I think is missing. I'm quite pleased
with my upstream service provider. :-)


... Gone crazy, be back later, please leave message.
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Aug 13 14:08:48, you wrote to me:

Include Upload Date in File Descriptions:

that wording makes me think the date will be in the file's description
block instead of in the file's date field in the data record...

That's correct. There is "file's date field" in the Synchronet filebase. A file's date/time is best taken from the file system, not a database.

it was done that way on the old system for speed... it was faster to read the date once when the file was added to the database and then show that instead of
hitting the drive every time for each file to pull the file's date and even size...

but it is also the upload date instead of the file's actual date... i
don't care about the upload date other than when doing a "new files
since" listing... that kinda means there would need to be two date
fields in the file records... one for the file and one for the
upload...

We do have an "upload date" field, but there's no mode to display
*that* date/time in the file listings. I do plan to make the file
listing format more flexible in the future. The various dates for a
file are displayed when looking a file's "extended info".

understood... knowing that future enhancement is in the works is one reason why
i'm asking about things and looking at features i used to use in my old software...

If you wish the upload date of each file in this directory to be
automatically included in the file description, set this option to
Yes.

yeah, not the upload date... the file's actual date... i actually have
a routine that goes through the files and ensures their archive date on
disk is the same as the date inside the archive...

When does that routine happen? If it's some time after the file was uploaded, then having sbbs add it (the file's date/time) to the file's description wouldn't really help ya (they'd be out-of-sync later when your routine ran).

in my case the routine ran and the database was updated afterward... i ran it manually generally when pulling in new batches of files... some transfer methods do not retain the original file data and time so i fixed that with my script and would them import the files into the database... sometimes i'd forget and notice later so the two steps, touch the file and update the database, had to be performed...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them. ... We have forty million reasons for failure, but not a single excuse.
---
* Origin: (1:3634/12.73)

On 2019 Aug 13 18:16:00, you wrote to me:

i don't know that it is limited to addfiles imports...

It may not be. I am still not convinced that the root cause of it
is just the missing 'size' definition in a TIC file... I get some
FDN files from othernets that show up properly, and I think it's
because all those TIC files have the size specified in them.

i dunno... my tickit does specifically check to see if there's a
file size and if not, it specifically takes it off the HD and
adds it to the TIC and to the addfiles tickit-files.bbs file for
importing into the BBS..

Is your Tickit any different than mine?

yes...

I'm using the stock version now, latest one. But I'm also a little confused by the above... I'm talking about the TIC files that I get
from you, none of them has a file size specified in the TIC file.

they should have been having the SIZE in them but i fixed the bug in the wrong area the other day... i've since found where i need to fix the code but have some thinking to do about an aspect or two so that it'll be fixed once and for all...

[trim]

that works, too...

Yes, one side-effect of using that though, is that files that get
replaced by a new one of the same name do not get recognized as a
"new" file, because the name was already in the database.

yes, that's a problem that i don't yet know the best way to handle... there should be some sort of filebase command line tool that we can use to update existing files... maybe addfiles does that but then we run into needing multiple command lines for tickit to choose from and then somehow tickit has to
keep up with what's already in the file base... it just needs some time to think about and develop a method of attacking the problem...

[trim]

To summarize my thoughts on this, I think that ALL tic files
should have the size of the associated file specified in them,

the file's size is an /optional/ line in the TIC file spec...

I'd like to see that get changed to a /required/ line.

that is unlikely to happen any time soon... ALLFIX set the defacto standard decades ago and other software implemented key parts... then the FTSC wrote their document so there was an actual paper somewhere with the basic details...
in doing so, they had to look at what all the known TIC processors did when handling and creating TIC files...

and I also think that maybe the parameters passed to addfiles within
tickit could be improved.

possibly but that depends on if the data desired already exists
or not... if it does then it is extra work for no gain...

But if it (the data desired) *DOESN'T* exist...

give me some time and i'll certainly be working in my stuff... then i can work out the patches needed to be applied to the stock tickit without all my extra logging stuff...

Now granted, I'm free to modify my copy of tickit.js any way I
want to, and I have, as mentioned above. But it would be nice to
have it work as a default configure, which can't be done if the
incoming TICs don't contain the needed data.

agreed with caveats...

I'm not really bitching about this, just trying to clarify what
I'd like to see, and what I think is missing. I'm quite pleased
with my upstream service provider. :-)

:)

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them. ... Live a little - butter both sides of the bread.
---
* Origin: (1:3634/12.73)

mark lewis wrote to Gamgee <=-

[trim]

and I also think that maybe the parameters passed to addfiles within
tickit could be improved.

possibly but that depends on if the data desired already exists
or not... if it does then it is extra work for no gain...

But if it (the data desired) *DOESN'T* exist...

give me some time and i'll certainly be working in my stuff...
then i can work out the patches needed to be applied to the stock
tickit without all my extra logging stuff...

No worries! Thank you for the effort you're putting in (and have
put into it in the past). It's a process...

I do appreciate it.


... Behind every great man is an amazed mother-in-law!
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)