This is actually working as designed. The user can lock files that have not yet been delivered to the stream. This however will not prevent other users from creating a different file with the same name (in the same location), and thus conflicts / evil twin scenarios can still occur. One benefit might be that you may know you want to work on this file across several change sets, and so you may want to lock it right away so that you don't forget to do so later (you can even lock it before checking in the new file). Thus you can lock this un-delivered file, and then deliver this new file to the stream at some future point without worrying about remembering to lock it as soon as you delivered it. This also removes any small 'window' where someone else may quickly modify that file and deliver their change. Also, if you were to complete the change set which added the file, but did not yet deliver the change set to the stream, it is still possible for someone else to flow to your repository workspace and accept the change set addition, and make changes of their own and deliver that to the stream, but by having it locked right away, it would prevent the delivery by the other person in this case