Hello g00r00!

I just noticed that if I upload a file which already exists (to some file area), the existing file gets overwritten. So someone could "destroy" a file by uploading another file with the same name but with different contents. And probably it will look like the original uploader uploaded the latest ("destroyed") file. Is there any way to prevent this?

Also, a file which has been deleted (Edit --> Delete) from the file listing will be considered still present (classified as a duplicate) by the upload function as long as mutil PackFileBases maintenance hasn't been run since the deletion. It doesn't matter whether the file actually exists on disk or not. Is there any way the dupe detection could ignore deleted entries? Or perhaps this would collide with some uniqueness constraint of the file base index files?

Best regards
Bj”rn

--- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)

I just noticed that if I upload a file which already exists (to some file 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.

Also, a file which has been deleted (Edit --> Delete) from the file listing will be considered still present (classified as a duplicate) by the upload function as long as mutil PackFileBases maintenance hasn't
been run since the deletion. It doesn't matter whether the file actually exists on disk or not. Is there any way the dupe detection could ignore deleted entries? Or perhaps this would collide with some uniqueness 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)

Hello g00r00!

Thank you for your reply!

On 05 Aug 2021, g00r00 said the following...

The duplicate file scan would prevent that from happening except when doing a blind batch Zmodem upload.

Ah, yes, that explains it, I was indeed using Zmodem...

Could some tempname stuff perhaps be used/help? For blind batch uploads, each received file is stored with a temporary name (but Mystic notes the desired name of each file) and is then renamed or deleted, depending on the findings of the duplicate check?

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.

Agreed!

I'll make a note in the TODO list.

Thanks! It's certainly not a "pressing" issue in any way, though, so no hurry.

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.

Agreed!

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

Please let me know if there are any further tests that I can do to aid you with this issue -- I'd be happy to help!

Best regards
Bj”rn

--- Mystic BBS v1.12 A47 2021/08/05 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)