• MUTIL request

    From Gryphon@46:1/116 to g00r00 on Monday, April 25, 2016 09:17:31
    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)
  • From g00r00@46:1/127 to Gryphon on Monday, April 25, 2016 11:50:26
    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)
  • From Gryphon@46:1/116 to g00r00 on Tuesday, April 26, 2016 08:18:55
    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)
  • From Gryphon@46:1/116 to g00r00 on Tuesday, April 26, 2016 08:20:30
    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)
  • From g00r00@46:1/127 to Gryphon on Tuesday, April 26, 2016 11:50:47
    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)
  • From Gryphon@46:1/116 to g00r00 on Tuesday, April 26, 2016 13:03:27
    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)
  • From Pequito@46:1/167 to g00r00 on Tuesday, April 26, 2016 15:33:33
    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)
  • From maskreet@46:1/148 to Gryphon on Tuesday, April 26, 2016 17:48:29
    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)
  • From g00r00@46:1/127 to Gryphon on Wednesday, April 27, 2016 08:23:54
    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)
  • From g00r00@46:1/127 to Pequito on Wednesday, April 27, 2016 08:24:46
    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)
  • From Gryphon@46:1/116 to maskreet on Wednesday, April 27, 2016 08:19:52
    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)
  • From Gryphon@46:1/116 to g00r00 on Wednesday, April 27, 2016 08:30:23
    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)
  • From g00r00@46:1/127 to Gryphon on Wednesday, April 27, 2016 10:38:25
    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)
  • From PureSkillz@46:1/143 to g00r00 on Friday, April 29, 2016 23:44:26

    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)
  • From PureSkillz@46:1/143 to g00r00 on Friday, April 29, 2016 23:47:30

    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)
  • From wkitty42@46:1/132 to Gryphon on Thursday, May 05, 2016 17:35:28
    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)
  • From Accession@46:1/100 to wkitty42 on Thursday, May 05, 2016 18:40:06
    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)
  • From Tiny@46:1/126.1 to Accession on Friday, May 06, 2016 16:50:22
    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)
  • From wkitty42@46:1/132 to Accession on Saturday, May 07, 2016 20:58:03
    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)
  • From g00r00@46:1/127 to wkitty42 on Friday, May 06, 2016 16:40:16
    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)