How to download multiple files with the same name?

When I download multiple files with the same name, they merge into one file.

If one download finishes, but the other doesn't, the file still shows as incomplete.

If I cancel one download, the other download will cancel too.

This didn't happen on a previous computer so I assume there is an option to prevent this, I just can't find it, thanks.

Simple. Assuming the files are indeed different even though they have the same name, just choose different download folders when you load their respective torrents.

That seems to be a lot of work, and I didn't have to do that before, I just got multiple files with the same name in the same folder.

Right now I am downloading 4 torrents with the same name, all slightly different sizes, but only one file in the download folder.

Sorry to burst your bubble my friend, but Windows is not Unix. I do suppose you're using uTorrent under Windows, right? In Windows, capitalization doesn't matter, so there's NO WAY you can have more than one file with the same name in the same directory, period. Try it yourself and see by creating two text files with Notepad with the same name in the same dir. If you can do it, a prize for you!

uTorrent hasn't changed its behaviour either in this regard. Multiple files with same name? They'll simply keep overwriting each other (I'm surprised uTorrent didn't throw up an "Access Denied" error for you till now!) till you have only one file left.

... files with the same name and different sizes means they are different content. DON'T USE THE SAME FOLDER if they're claiming to be the same name!

If they have differing HASHES uT should be programmed to pop-up an alert warning of imminent DATA LOSS anyways Windoze or not(!). In the P2P world there are a load of downloadable files with the same names that are actually different(!) - i'm totally surprised that uT just overwrites the file and does not even check and tell you! How primitive!

While I'm surely not the ONLY person to appreciate your comments... You don't provide any... logic? I guess is the word i'm looking for. BitTorrent is based upon INFOHASH. If different files (read as: different INFOHASH) are loaded into uT, it is a separate torrent job and as such will report as a separate torrent which you control all aspects of it.

I suspect submachine is mis-remembering as ajones81 says, uT doesn't like it when other programs (including itself) open the files it has open for writing ALSO in WRITE mode. uT will spit an error: Access Denied in that case whereby multiple torrent jobs are trying to access the same filename until only the last one is left.

I'm not sure if it's so much write access as it is exclusive file locking that's causing the "access denied" errors.

@Cor'eCor'e: BitTorrent has absolutely no concept of files -- only pieces. As such, µTorrent does not have access to the hash of the files in any torrent being added. Not possible to begin with. µTorrent does hashcheck the files before overwriting. µTorrent can't tell if it's a problem with the data being corrupt (and that the user is trying to resume), so why shouldn't it overwrite unwanted data (unwanted with respect to the pieces described in the .torrent metainfo)?

@Ultima: I'm glad you give more detail, i was using Azureus as well and it seems to handle multiple torrents downloading into the same file(s), it has the option"Enforce exclusive file write access locking across torrents", now i see the function of this clearer with your explanation.

I was looking for that feature in uTorrent but it seemed always greyed-out "Advanced>Set Download Location..." until i actually stopped the download(s), then things like that and "Force Re-Check" became selectable.

I don't want to go off topic, this was a topic i looked at because i wanted to know how to set multiple torrents to actually download into the same files (assuming i made sure they would be the exact same files first!), i was alarmed that hash checking was not part of the logic in the loop.

Would you be so kind as to explain more on your statement: "µTorrent does hashcheck the files before overwriting."

When you add the torrent, when you change the download location, and after improper shutdown uT automatically rechecks affected files in the torrent.

It checks the file to find existing data before it decides to overwrite it completely. If it finds existing data, it'll resume.

And yeah, you shouldn't be setting the download location while µTorrent is using the file, and hash-checking while the file is in use doesn't really make much sense either. So that's why both options are disabled until you stop the torrent.

@Ultima: If it finds existing data, if i intend to have two or more torrents downloading into the same exact file(s), will i ever see uTorrent deleting the pre-existing partial data blocks in the process of each torrent adding its partial data blocks to the file(s)? or has that bit of logic been made good since after all uTorrent does allow multiple torrents to download into a single file... I won't be doing things uT won't allow me to do...

I'm not entirely sure how µTorrent would behave if it were downloading to the same location for 2 separate torrent jobs, but I'd imagine it would be confused. There's only so much µTorrent can do to think for the user. If µTorrent were to warn about existing files, then it would annoy users who know and are trying to reload an existing torrent (something I'm quite certain happens more often). µTorrent would only be doing what the user told it to do, so if the user can't figure out that they shouldn't be downloading 2 unidentical files to the same location, then maybe they deserve to be shot in the foot? O.o

Having come from Azureus where it "does" this, i assumed it was a common supported BT practice, if uTorrent does this only blindly and only at the bequest of the user, so you say it is not really a normal use or practice to do this then i better double-check on Azureus as well before i lose a toe, heh!

Backing up a bit, i was saying uT should warn when the torrent file hashes do not match... which was already threaded out i think. We're not talking about unidentical files, unless there was corruption somehow during DL...

Azureus supporting randomly overwriting the same file is bad coding/feature/bug... You are telling one torrent to download to a file, GREAT! You are telling a different torrent to download to the SAME file, NOT GREAT! That it doesn't spit out an error "unable to open file, file locked" seems like an oversight to me.

When UPLOADING, uTorrent doesn't care about data content. If you tell uT "go to X file" it will check the existing file, go to 100% if complete and start seeding. If your two torrents do not both say 100% then the content is not exact. The nature of byte-for-byte copies ensures this is the case. Your "warning" about hashes not matching is met when.. uhm it adds a different job for the torrent instead of asking "The torrent you are trying to add is already in the list of torrents. Do you want to load the trackers from it? Y/N". Does that explanation make sense?

I just noticed "Pre-allocate all files" is NOT checked now, but it was checked on the other computer. It is possible that when this was selected, different files with the same name were all pre-allocated (perhaps windows renamed each?) and downloaded separately.

And when it is not checked, the files are not pre-allocated separately but saved over eachother, as one.

In all cases since windows does not recognize case in filenames, windows would try to access the same file for each instance. Given they are all different sizes when the first is outside a smaller bound the filesize would increase. This would result in a useless file for ALL FOUR torrents in azureus. If it doesn't it's renaming something. uT doesn't accept the inability to access the file and will error out. In uT you can set the filename of individual files through stop, right click, advanced, change download location. Implementation of this in multi-file torrents exists in 1.8.

heyhey... no badmouthing here...

Azureus supporting randomly overwriting the same file is bad coding/feature/bug

It's an optional feature and we warn users about it. It's certainly not "randomly" but covered with various sanity checks...

I apologize for the badmouthing... but in any case that feature is NOT going to help in the afforementioned case where the file is not the same. It's main benefit comes when you are trying to bridge two swarms with different infohashes which comprise the same file (filesize) right?

indeed, if the file sizes or hashes mismatch then one must use different files, otherwise both torrents would corrupt each other