Shareaza

When trying to rename files that are being downloaded, it never saves the new name that I change them to. This was not a problem up until 2.4.0.0 and I thought it would have been addressed in the 2.5.1.0 release, but was not so I figured I would let everyone be aware of this bug.

others seem to also be having problems with files not being properly renamed when being moved from the incompletes folder. Thank you for alerting us of this issue. You can help us test/fix this bug if you like by trying the most recent debug build and confirming if/when it has been fixed.

Just a comment that this is the most annoying bug in the latest builds of shareaza. Without files auto renaming if file name exists files are lost and have to be re downloaded. Often files are lost without realising. Hope we get a fix soon.

I ran to this while fixing corrupted files. Download from the same link, merge with the corrupt file, and Shareaza only downloads the corrupted part. And as you can imagine the file names were almost always identical... Anyway, from my experience, it might be better to check for the file name already existing and then prompt the user to deal with it than to auto-rename. This because in my case the correct solution was deleting the older file, not having two almost identical files with almost identical names. No idea if cases like this are common enough to justify the extra work from developer...

Having the client auto rename files it downloads that have the same name is a fairly standard feature in p2p clients. It was default behaviour for Shareaza before version 2.5. In the case of MP3 files it can sometimes be a necessity.
By auto rename I only mean adding (1),(2),(3)..etc to the end of the filename.

edit. Sorry Ailurophobe. I didn't read your post carefully enough.

Yes it would be good if Shareaza asked what the user wanted in some situations. Perhapse there should be an option to switch between renaming automatically and asking for user input.In some cases it would be inconvenient for shareaza to ask though. Like when the user was using shareaza unattended.

this is most-likely a regression due to raspopov's new filesystem branch being merged into trunk.

this bug may have been fixed in rev.9159. Since this bit of code is currently being worked on, now is your best chance to have it fixed if it is still not working.