Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    MYSTIC    |    Mystic support echo    |    16,010 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 13,711 of 16,010    |
|    g00r00 to Bj”rn Wiberg    |
|    Re: Duplicate uploads overwrite + dupe d    |
|    05 Aug 21 13:00:33    |
      TID: Mystic BBS 1.12 A47       MSGID: 1:129/215 f0c0c433       REPLY: 2:201/137 aee37540       TZUTC: -0400        BW> I just noticed that if I upload a file which already exists (to some file        BW> area), the existing file gets overwritten. So someone could "destroy" a              The duplicate file scan would prevent that from happening except when doing a       blind batch Zmodem upload.              I think if I change this I would need to make it configurable. My belief is       that the more likely situation is that someone would be uploading a same file       to fix a broken or corrupt file, not using a blind upload Zmodem attack to       corrupt a file. But you are right that could in theory happen.              If I change how it works now, then that scenario would require a SysOp to       manually remove the file so the user could upload it again as opposed to a       user being able to contribute a new file on their own. Because of that I       think I'd need to make a configurable option for the SysOp to decide.              I'll make a note in the TODO list.               BW> Also, a file which has been deleted (Edit --> Delete) from the file        BW> listing will be considered still present (classified as a duplicate) by        BW> the upload function as long as mutil PackFileBases maintenance hasn't        BW> been run since the deletion. It doesn't matter whether the file actually        BW> exists on disk or not. Is there any way the dupe detection could ignore        BW> deleted entries? Or perhaps this would collide with some uniqueness        BW> constraint of the file base index files?              The file being on disk doesn't matter and this is needed because you may have       files OFFLINE but still in your file bases that are cycled in from external       media (designed like this for CD changers but in more recent times maybe you       rotate USB drives). In those cases you'd want the dupe scan to continue to       detect them even though the file is not physically there.              As far as the delete thing, yes that should remove the index entry so this is       a bug based on your description. Packing is a temporary fix since it should       regenerate the indexes when it packs but it shouldn't require it.              ... Anything is possible if you don't know what you're talking about              --- Mystic BBS v1.12 A47 2021/07/31 (Windows/64)        * Origin: Sector 7 * Mystic WHQ (1:129/215)       SEEN-BY: 1/123 90/1 103/705 105/81 120/340 457 616 123/10 131 124/5016       SEEN-BY: 129/215 305 154/10 30 40 50 700 203/0 220/80 90 221/0 6 226/18       SEEN-BY: 226/30 227/114 201 702 229/101 310 424 426 428 452 550 700       SEEN-BY: 229/981 1016 1017 240/1120 5411 5824 5832 5853 6309 249/206       SEEN-BY: 249/307 317 400 280/464 5003 282/1038 292/854 8125 301/1       SEEN-BY: 317/3 320/219 322/757 342/200 396/45 633/280 770/1 2452/250       SEEN-BY: 2454/119 3634/12       PATH: 129/215 154/10 280/464 240/5832 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca