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
name, date and descriptions but i'm not finding anything for the file's size :(anyone know how i can get the file size in my files list? i can get the
/sbbs/data/dirs/newuplds/sestar.lst/sbbs/exec/filelist - -- -dfd -hdr -jst -noe
The credit value is usually the same as the file's size, so the "-cdt"optino should work for you. No?
/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...
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 ;)
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
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 ;)
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?
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.
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 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...
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...
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...
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
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.
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.
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.
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...
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..
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...
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).
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.
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.
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. :-)
mark lewis wrote to Gamgee <=-
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...
Sysop: | Zazz |
---|---|
Location: | Mesquite, Tx |
Users: | 7 |
Nodes: | 4 (0 / 4) |
Uptime: | 13:31:55 |
Calls: | 157 |
Files: | 2,103 |
Messages: | 144,386 |