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
