I would think that all the files are 'bad' in some way but the command is just accessing the files in a different order when run in the two different ways. All the files have to be read at the initial phase of the import.
I think you'll likely find that if you change the order of the files in your second command the bad file will be reported as a different file - oracle often validates things from right to left.
The % option is probably ordering the files in some random sequence and it just so happened that TEST03.dmp was checked first.
The most likely cause of the error is that the files were transferred to the server in the correct ftp mode.
Please let me know whether the dump was transferred from another server to 11g database server ,
If yes please check the sizes of dump files on source & destination servers ,you can also use cksum to check files.
The Backup was located on an the windows Drive and the file size is all the same.How can we check the cksum of a file in windows.
Thanks.it means there are no inbuilt functionality to check the cksum in windows we have to install this package for it.
Really you inputs were a great help for me
Can you confirm that the export on the source was taken with expdp and not original exp ?
The export was taken on the Source using expdp.