home bbs files messages ]

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