Theb flag of the copy command treats the files as binary (i.e., a raw stream of meaningless bytes), and copies them byte for byte instead of the default (or the /a) behavior which treats them as lines of text (with end-of-line characters, end-of-files, etc.)
As you can see, each file will contain a file-level header with some general information, followed by data blocks for each page containing the page data. If you then take two files, each containing one page and merge them as binary files, you will not be creating one two-page file, but instead one corrupt file that starts out with one page, then has a bunch of junk (the file header makes no sense when the program tries to read page two).
The copy command knows nothing about file-types other than plain-text (and even then, only ASCII text), so only plain-text can be combined correctly with it. Binary files must be combined using an editor that knows how to parse and interpret the contents correctly.
In your example, with MP3s, it will probably give weird behaviours because of how MP3s get encoded. For example, the ID3v1 tags are the last 128 bytes of an MP3 (i.e. artist, album, etc). This information is not "playable". When VLC or another media player opens up the MP3, it will (probably) play through the first MP3, act funny for the information, and then possibly play through the rest of the file. I don't have Windows loaded right now, so I can't test for sure.
I would assume this is the same as images and movies; depending how the files are encoded depends how the files will "combine". I imagine this functionality came from the days of DOS when everything was in plain text
But what on earth makes you think that if you have two audio files and just combine them into one file, byte by byte, what on earth makes you think that's going to work to produce a playable file without any issue. It might work but there's no reason for you to necessarily think it certainly will.
Suppose there's a thing at the top of an audio file that says " start of audio file ". So now you're going to get the words " start of audio file " occurring twice in the resultant file if you were to just combine them byte for byte. That might lead to an error mightn't it.
Even using copy /b or even copy, to combine two text files might not work. eg what if there's something at the start of the text file, like some bytes to say it's the start(like a UTF-BOM), that should only be at the start. And you don't want that occurring twice.
Regarding the MP3, roughly, what's after the header can all be read as data. There's this game, Sonic 3 in Sega Genesis and another game called Sonic & Knuckles. The Sonic & Knuckles original cartridge had a slot intended to insert other games, but when added Sonic 2 and specially 3, probably the checksum would trigger another set of pointers, the game would behave differently. In early stage of using ROMs, whenever we wanted to put two cartridges to work like it was in the hardware, we used copy /b sonick.bin+sonic3.bin sonic3k.bin. This way, their merge would result in one big single ROM where sonick would have the instruction set (pointers) to make it use sonic3 resources.
You can also use the copy command, with different parameters, from the Recovery Console. For more information about the recovery console, see Windows Recovery Environment (Windows RE).
If a write operation cannot be verified, an error message appears. Although recording errors rarely occur with the copy command , you can use /v to verify that critical data has been correctly recorded. The /v command-line option also slows down the copy command, because each sector recorded on the disk must be checked.
If the connection is lost during the copy phase (for example, if the server going offline breaks the connection), you can use copy /z to resume after the connection is re-established. The /z option also displays the percentage of the copy operation that is completed for each file.
If you don't specify a destination file, a copy is created with the same name, modified date, and modified time as the original file. The new copy is stored in the current directory on the current drive. If the source file is on the current drive and in the current directory and you do not specify a different drive or directory for the destination file, the copy command stops and displays the following error message:
If you specify more than one file in source, the copy command combines them all into a single file using the file name specified in destination. The copy command assumes the combined files are ASCII files unless you use the /b option.
If you combine files, the copy command marks the destination file with the current date and time. If you omit destination, the files are combined and stored under the name of the first file in the list.
For windows users, if you use (Shift + right-click) on any files in the file explorer or the desktop.
You will get a new entry in the right-click menu witch is call copy as path click on it to get the full path in the press-paper.copyaspath613510 79.8 KB
The command above will copy source to destination, files and directories (including empty ones), will not stop on error, will copy hidden and system files, will overwrite read only files, will preserve attributes and ownership/ACL information, and will suppress the prompting for overwrite existing destination files.
Use ROBOCOPY if you're creating backup scripts. xcopy has been deprecated and will likely be phased out of use in the near future. robocopy can do everything xcopy can. It is also more flexible and reliable. Creating scripts with robocopy will future-proof them.
Use robocopy to easily copy folders. The robocopy command replaces the xcopy command. It can quickly copy entire folders without having to worry about defining the contents. For example, to copy all of the contents of the C:\tools directory to the new folder D:\backup\tools, enter the following:
The /e modifier tells robocopy to include all subdirectories. This includes empty folders.robocopy will automatically copy hidden and system files. It will create new directories if they don't exist at the target location.
Mirror a directory. Mirroring a directory is great for making backups. The mirror option of robocopy will copy all of the contents from the source to the destination. It will then delete anything at the destination that doesn't exist at the source. This ensures that your backup only has the latest versions of your files. For example, to mirror C:\Users\My Documents to D:\backup\My Documents, enter the following:[4]
if not exists checks the parameter to see if it exists, but it only works on files. To check for existence of a directory, you need to look for a 'pseudo-file' called "nul" - checking for existence of this file will always return true if the directory exists.
If you want the ability to synchronise the copy and other advanced features (ignore certain folders, only include certain wildcards) then look at robocopy. Included in Vista and beyond, optional (from resource kit tools) in earlier versions.
xcopy will create the directory structure for you. Trick is to use the /I option and throw an asterisk at the end of the file name so xcopy thinks you're copying multiple files, otherwise it asks you if the target name is the file name you want, or the directory name you want. For example.
Before using cross-device copy and paste for the first time, you'll need to make sure the feature is turned on. Open the Phone Link on your PC, go to Settings > Features > Cross-device copy and paste, and make sure the toggle is On for Allow this app to access and transfer content I copy and paste between my phone and PC.
Use your mouse to long press again on the file(s) you've selected, and a thumbnail will appear. Drag the files to your desired location on your PC. The cursor will change to indicate when you're able to drop the file(s).
Use your mouse to long press on the photo(s) you've selected, and a thumbnail will appear. Drag the photo(s) to your desired location on your PC. The cursor will change to say Copy when you are able to drop.
By default, content you drag from your PC to your Android device will be saved to your My Files app. Some apps, like OneDrive and Outlook, will allow you to directly drop content into them. If a file can't be dropped into the app you intended, it will be transferred to your My Files app on your Android device instead.
Once you've opened Phone screen in the Phone Link, use your mouse to select the file(s) you'd like to transfer and drag them to the phone screen window. The cursor will change to say Copy when you're able to drop.
When a successful file transfer is made, you can either tap the notification that appears on your Android device, navigate to the app you dropped your content into, or go to your Internal Storage > Download folder to view your files.
File drag and drop supports the transfer of all file types except for folders and files backed up to the cloud. You can transfer up to 100 files at a time, of any type. No single file can be larger than 512MB in size.
The item being transferred is not supported. For example, if even just one of the items you are dragging is a folder and not a file, or you try dragging 100 files, your Android device won't allow you to start a transfer.
3a8082e126