g00r00,

I'd like to make a request for MUTIL. Can you make an option in the MassUploads section to use the date of the file on disk, rather than the current date that the process was run? I have found that during the recent upgrades with the need to do a reset on all the file areas, it has caused all my files to be uploaded on the same date; the date when I ran the massuploads process. Now every file looks like a new file. :(

"No matter where you go, there you are!" - Buckaroo Bonzai

--- Mystic BBS v1.12 A11 (Raspberry Pi)
* Origin: Cyberia BBS | Cyberia.Darktech.Org | Kingwood, TX (46:1/116)

current date that the process was run? I have found that during the recent upgrades with the need to do a reset on all the file areas, it

There was never a need to do a reset on the file areas? I do not understand.

--- Mystic BBS v1.12 A12 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

On 04/25/16, g00r00 said the following...

current date that the process was run? I have found that during the recent upgrades with the need to do a reset on all the file areas, it

There was never a need to do a reset on the file areas? I do not understand.

This is what made me think that I had to do a reset. I was having the same issue with mutil and massupload crashing. --------------------------------------------------------------------------- From: g00r00 To: Alan Ianson
Subj: Re: Mystic BBS v1.12 Alpha 8 Released
Date: 03/26/16 05:23
Base: [FSXNet] General
...

Speaking of which, have you tried the online mass upload and does it crash as well? If you havent tried, reset your listings (I'm assuming thats what you're doing) and then run the MUTIL file base packer to recreate the indexes...

Then try the mass upload while logged in from the file menu and see what happens.

If it doesn't crash, you should be able to use the online mass upload successfully without dupe files since it wasn't compiled as Windows.

--- Mystic BBS v1.12 A8 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108) ----------------------------------------------------------

"No matter where you go, there you are!" - Buckaroo Bonzai

--- Mystic BBS v1.12 A11 (Raspberry Pi)
* Origin: Cyberia BBS | Cyberia.Darktech.Org | Kingwood, TX (46:1/116)

On 04/25/16, g00r00 said the following...

current date that the process was run? I have found that during the recent upgrades with the need to do a reset on all the file areas, it

There was never a need to do a reset on the file areas? I do not understand.

Ok, regarless, my request still stands. Can the MassUpload feature have an option to glom off the file date rather than the run date?

"No matter where you go, there you are!" - Buckaroo Bonzai

--- Mystic BBS v1.12 A11 (Raspberry Pi)
* Origin: Cyberia BBS | Cyberia.Darktech.Org | Kingwood, TX (46:1/116)

Ok, regarless, my request still stands. Can the MassUpload feature have
an option to glom off the file date rather than the run date?

If I do that it will break new file scans.

--- Mystic BBS v1.12 A12 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

On 04/26/16, g00r00 said the following...

Ok, regarless, my request still stands. Can the MassUpload feature ha an option to glom off the file date rather than the run date?

If I do that it will break new file scans.

How so? If 10 files get added (via file copy or ftp upload or binkp copy),
one each over the next 10 days, then you run the massupload, it will look as
if each of those 10 files were added on the same day. Whereas if you run a massupload with the file date rather than the run date, you will have a true date stamp for the file in the file list.

"No matter where you go, there you are!" - Buckaroo Bonzai

--- Mystic BBS v1.12 A11 (Raspberry Pi)
* Origin: Cyberia BBS | Cyberia.Darktech.Org | Kingwood, TX (46:1/116)

On 04/26/16, g00r00 said the following...

Ok, regarless, my request still stands. Can the MassUpload feature ha an option to glom off the file date rather than the run date?

If I do that it will break new file scans.

I do not see this as breaking but an TRUE/FALSE option in the MassUpload section of the INI file so one can re-upload files so they do not seem new again when they are not. I believe that is what Gryphon was pointing at. :)

--- Mystic BBS v1.12 A11 (Windows)
* Origin: Twinkle BBS | (46:1/167)

On 04/26/16, Gryphon said the following...

If I do that it will break new file scans.

How so? If 10 files get added (via file copy or ftp upload or binkp copy), one each over the next 10 days, then you run the massupload, it will look as if each of those 10 files were added on the same day. Whereas if you run a massupload with the file date rather than the run date, you will have a true date stamp for the file in the file list.

Because a lot of files might have time/date stamps from years ago. The way a BBS looks for new files in a new file scan is by the upload date. If it went
by the file's time/date stamp, nobody would ever know what's a new file and what wasn't.

--- Mystic BBS v1.12 A11 (Windows)
* Origin: http://www.throwbackbbs.com -\- meriden, ct -\- (46:1/148)

Ok, regarless, my request still stands. Can the MassUpload featu an option to glom off the file date rather than the run date?

If I do that it will break new file scans.

How so? If 10 files get added (via file copy or ftp upload or binkp

A new file scan shows files that were added since the user's last new file scan, so it really has nothing to do with the actual date of the file. If Mystic used the date of the file instead, then new file scans would be completely broken.

For example:

If you mass upload a set of files into your BBS dated from 1992 (which so many of us do for legacy BBS software) they would never show up on any user's new file scan if the actual file date was used (1992).

Instead, Mystic must capture the time the file was added into the BBS and if the user last logged in before that date, then the file is new. In other words, uploading 100 files from 1992 will still show up properly in the new scan because its based on the date of the upload, not the file date.

--- Mystic BBS v1.12 A12 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

I do not see this as breaking but an TRUE/FALSE option in the MassUpload

Can you explain to me in detail how it will not break? I like to think I
have a pretty good grasp on this stuff, so if you think I am wrong then
please give me a technical rundown of how the new file scan continues to work if I used the actual file date instead.

--- Mystic BBS v1.12 A12 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

On 04/26/16, maskreet said the following...

On 04/26/16, Gryphon said the following...

If I do that it will break new file scans.

How so? If 10 files get added (via file copy or ftp upload or binkp copy), one each over the next 10 days, then you run the massupload, i will look as if each of those 10 files were added on the same day. Whereas if you run a massupload with the file date rather than the ru date, you will have a true date stamp for the file in the file list.

Because a lot of files might have time/date stamps from years ago. The

Yes. Exactly. And if I had to repair my file lists from scratch, using massupload, it would appear that those years-old files were brand new and
just uploaded today.

way a BBS looks for new files in a new file scan is by the upload date.

Exactly. And if the file was uploaded years ago, I don't want it to appear
as if it was uploaded today.

If it went by the file's time/date stamp, nobody would ever know what's
a new file and what wasn't.

It sounds like you are assuming that an uploaded file will have a time stamp
of when it was origionally created, whether it was today, or a decade ago. That is not the case. When a file gets uploaded, the date/time stamp of the file is changed to the date/time of the actual upload.

It appears as if we are arguing for the same thing. But we have different views on how it can be obtained. I think it is more accurate to use the file date and not the date at the time of performing the massupload.

"No matter where you go, there you are!" - Buckaroo Bonzai

--- Mystic BBS v1.12 A11 (Raspberry Pi)
* Origin: Cyberia BBS | Cyberia.Darktech.Org | Kingwood, TX (46:1/116)

On 04/27/16, g00r00 said the following...

Ok, regarless, my request still stands. Can the MassUpload an option to glom off the file date rather than the run dat

If I do that it will break new file scans.

How so? If 10 files get added (via file copy or ftp upload or binkp

A new file scan shows files that were added since the user's last new
file scan, so it really has nothing to do with the actual date of the file. If Mystic used the date of the file instead, then new file scans would be completely broken.

Not "completely" broken. If the file date was the same as the upload date, then there is no harm, no foul, right?

For example:

If you mass upload a set of files into your BBS dated from 1992 (which
so many of us do for legacy BBS software) they would never show up on
any user's new file scan if the actual file date was used (1992).

Thats only true if the file has been sitting on the same disk since 1992 without being moved or copied around. I'd wager that in most cases, the files have been copied to the BBS computer at some point since then, and will
reflect the date of the copy and not the original creation date of the file.

Instead, Mystic must capture the time the file was added into the BBS
and if the user last logged in before that date, then the file is new.
In other words, uploading 100 files from 1992 will still show up
properly in the new scan because its based on the date of the upload,
not the file date.

I can see your point. But this is why I wanted it to be an OPTION, and not a fixed method of doing business.

Because if you look at the other scenario, where a sysop has to rebuild their file lists from scratch, then it would appear as if all the files were added
in one day. Which is also not be true. Then all those files would appear
new, when in fact they are not. Then actual new files would get lost in the tide of false new files.

"No matter where you go, there you are!" - Buckaroo Bonzai

--- Mystic BBS v1.12 A11 (Raspberry Pi)
* Origin: Cyberia BBS | Cyberia.Darktech.Org | Kingwood, TX (46:1/116)

Because if you look at the other scenario, where a sysop has to rebuild their file lists from scratch, then it would appear as if all the files were added in one day. Which is also not be true. Then all those files

There is not a scenario where you have to rebuild your file lists from scratch. I get that you decided you wanted to do that, but Mystic is acting as it should by showing newly added files as new.

The reason why I don't want to add an option like you're asking for is because people turn things on without understanding what they do. It happens OFTEN...

If a person turns that feature on, it will break their new file scans. This will make Mystic appear unstable, and it will force me to clean up the mess they make.

You created a new database and Mystic is showing files as new that you've
newly added into the BBS. Its functioning as it should, and your scenario doesn't ever happen unless you start deleting things you shouldn't.

You should be able to work around this though, without needing that feature. If you delete the *.SCN files in the DATA directory, Mystic will regenerate the scan settings, setting the current day as the last new scan date.

In other words, if you mass uploaded 20,000 files yesterday, you should be able to go in today and delete *.SCN, and those 20,000 files will not show up in a new scan for any new or existing user.

--- Mystic BBS v1.12 A12 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

Hello g00r00!

27 Apr 16 08:24, you wrote to Pequito:

Can you explain to me in detail how it will not break? I like to
think I have a pretty good grasp on this stuff, so if you think I am
wrong then please give me a technical rundown of how the new file scan continues to work if I used the actual file date instead.

g00r00:

I think that Gryphon needs a switch in MUTIL to use in disaster recovery scenarios only not as a standard way of adding files into the BBS.
The actual way MUST be the default way to do it but I also think that to have the alternate option as a method of repairing/recovering from a
disaster is not completely insane either.

P.

--- GoldED+/LNX 1.1.5-b20150715
* Origin: The Wall Caribbean & Central American Hub (46:1/143)

The reason why I don't want to add an option like you're asking for is because people turn things on without understanding what they do. It happens OFTEN...

I agree with you here also.


PureSkillz


--- GoldED+/LNX 1.1.5-b20150715
* Origin: The Wall Caribbean & Central American Hub (46:1/143)

On 04/26/16, Gryphon said the following...

If I do that it will break new file scans.

How so? If 10 files get added (via file copy or ftp upload or binkp copy), one each over the next 10 days, then you run the massupload, it will look as if each of those 10 files were added on the same day. Whereas if you run a massupload with the file date rather than the run date, you will have a true date stamp for the file in the file list.

FWIW: RA has three dates in its files directory... the file's actual date,
the upload date and the last download date... part of my processing is to ensure that the file's actual date is as accurate as possible because some files when transferred with some methods get the date of download instead of carrying the original date... i fix them by setting the file's date to the newest of the internal files in the archive... some dates are irrevocibly
lost for files that are not archives or that i cannot look inside of...

--- Mystic BBS v1.10 A57 (Windows)
* Origin: (46:1/132)

Hello wkitty42,

On 05 May 16 17:35, wkitty42 wrote to Gryphon:

FWIW: RA has three dates in its files directory... the file's actual
date, the upload date and the last download date... part of my
processing is to ensure that the file's actual date is as accurate as possible because some files when transferred with some methods get the date of download instead of carrying the original date... i fix them
by setting the file's date to the newest of the internal files in the archive... some dates are irrevocibly lost for files that are not
archives or that i cannot look inside of...

Yeah, but RA is so ugly to look at. :) :) :)

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160322
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/100)

Accession wrote in a message to wkitty42:

Yeah, but RA is so ugly to look at. :) :) :)

I've seen some killer customized Remote Access systems over the years. Hell my own (I wish I still had it) looked like PCBoard more then RA.

Though I do love the interface of the RA style boards, (Hence my love for Ezycom I guess!)

Shawn
... An argument is where two people are trying to get the LAST word in FIRST! ---
* Origin: Tiny's Trailer (46:1/126.1)

On 05/05/16, Accession said the following...

FWIW: RA has three dates in its files directory... the file's actual date, the upload date and the last download date... part of my processing is to ensure that the file's actual date is as accurate as possible because some files when transferred with some methods get th date of download instead of carrying the original date... i fix them by setting the file's date to the newest of the internal files in the archive... some dates are irrevocibly lost for files that are not archives or that i cannot look inside of...

Yeah, but RA is so ugly to look at. :) :) :)

so change it just like you do mystic or synchronet... no ""mods"" needed ;)

--- Mystic BBS v1.10 A57 (Windows)
* Origin: (46:1/132)

FWIW: RA has three dates in its files directory... the file's actual
date, the upload date and the last download date... part of my

Mystic has these file dates too.

--- Mystic BBS v1.12 A13 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)