Shareaza systematically overwrites a file if a file with the same name is received in the same folder

[abolibibelot1980]

This is a really egregious bug : whenever a file is completed which has the same name as a file already present in the reception directory, it silently OVERWRITES the former file with the new one. Then strangely the newer file will appear with the status “unverified”, even though it is the one which replaced the other, while the former file retains its “verified” status (even though it has vanished), but will appear in orange in a search or user browsing tab, which according to Shareaza's color schemes corresponds to a file which has been moved or deleted. So I have to constantly check the reception directory and move files quickly to avoid this as much as I can (I created a script[*] for that purpose), but it still happens once in a while. This is a major issue as I often download very rare files which have only one source, and that source can be available for a very short while then vanish. And it means that it is not possible, for instance, to download simultaneously several sets of pictures (for instance) with the same naming scheme like “001.jpg, 002.jpg, 003.jpg...” as only one file with a given name will remain in the end. That issue had already been reported in 2010 based on that thread, but still hasn't been fixed in the most recent official release from 2017 which is completely dumbfounding.

[*] If anyone is interested, here's the script in question :

chcp 1252
CD "[path to Shareaza's reception directory]"
setlocal enabledelayedexpansion
echo off
FOR %%F in (*) DO (
    IF EXIST ".\A CLASSER\%%~nxF" (
        FOR /F "tokens=1,2,3,4,5 delims=/: " %%T in ("%%~tF") DO set date=%%V%%U%%T%%W%%X
        FOR /F "usebackq tokens=1 delims= " %%E in (`fsum -edonkey "%%F"`) DO set ED2K=%%E
        move "%%F" ".\A CLASSER\%%~nF [!ED2K!] [!date!]%%~xF"
    )
    IF NOT EXIST ".\A CLASSER\%%~nxF" move "%%F" ".\A CLASSER\%%~nxF"
)
pause

It relies on the fsum command line utility, which allows to compute various kinds of checksums, including the MD4 based ED2K checksum used to identify files on the ED2K network. You can replace it with another checksum if you prefer, for instance use “-md5” instead of “-edonkey” to get MD5, or “-crc32” to get a shorter CRC32 string which is specific enough for that purpose. It works with the french date format, but may have to be tweaked to account for another date format. Likewise, the codepage setting “chcp 1252” may have to be changed according to your language, or it may fail to properly recognize some common characters. It may fail anyway if a file name contains characters only available in Unicode.

[abolibibelot1980]

I have yet to see if that issue is still present in the latest release or has been solved, but I could see several possibilities to deal with it, rather than simply adding a number as a suffix (as Windows Explorer does). – Either add as a suffix the added date (which is normally identical to the creation date, but only if the download was added with “Download now”, if the download was added with “Download” the .partial file is not created right away but only when the download is actually started — which is another (small) issue in itself), with a 1 sec. accuracy. For instance: "original file name [20221229163544].ext" – Or add as a suffix the file's hash, but then there are several to choose from, and they are quite long strings (at least 32 bytes), could be a problem with file names already long and/or if the reception directory is deep in the hierarchy and already has a long path (apparently the issue of Windows Explorer's inability to deal with paths longer than 263 characters has been solved itself in a Windows 10 update — but there are still quite a few users of older versions). – Or add both the hash and the date as I did in my script above. A choice could be given in an advanced option.

[ansani]

Ok, found the issue. Bug confirmed! I'm fixing it.

This is the actual strategy (by the Shareaza client):

All existent files are REPLACED (MOVEFILE_REPLACE_EXISTING) by default.

I modified the approach to check if a file already exists in the target directory. If a file is present, then the client will rename the file adding a "(TIMESTAMP)" just after the file name and before the extension (i.e. the target file _THIS_IS_ASAMPLE.TXT will be renamed to _THIS_IS_ASAMPLE (20221229182943).TXT)

[ansani]

This is not really a bug as I found a specific option in shareaza to rename the downloaded file if it exists. Plan to remove my new code