Backing up files using Robocopy

The default copy switch of robocopy is /COPYAT if you don't specify any copy options. This is the code I'm using:

robocopy C:\ D:\Backup RAMDisk.img /copyall /R:5 /W:15 /V /log:\Users\Kevin\Desktop\robocopy_log.txt

The RAMDisk.img file that I'm copying is a compressed image file. Now with that syntax /COPYAT will be used which means that it will copy all attributes of that file. Whenever I run this, I successfully copy the file but it doesn't retain the compression attribute of that file.

What could be wrong with this? Both source and destination are NTFS-formatted.

Although compression is indicated via a file's attributes, I'm not sure if that particular property actually transfers with the copy, even with Robocopy. If you copy to a compressed folder (folder and contents) then I would think the copy would be compressed. And if that folder is not compreesed, files that are placed there will be uncompressed (even if you are copying a compressed file to that location).

sibbil said:

Although compression is indicated via a file's attributes, I'm not sure if that particular property actually transfers with the copy, even with Robocopy. If you copy to a compressed folder (folder and contents) then I would think the copy would be compressed.

But I want only that specific file to be compressed though, is there any other way? I tried using the /a+:c switch of robocopy wherein it compresses the file when it is already in the destination folder regardless of the attributes of the original file but when it gives me an error of "cannot change attribute because file is accessed by another program" or something within those lines.

Does it work this way with any of the other files you move?

For a test, see if you can manually compress the destination file after copying it over.

sibbil said:

Does it work this way with any of the other files you move?

For a test, see if you can manually compress the destination file after copying it over.

Yes, I tried another file and it has the same problem.

I did manually compress the file after copying it over and it worked without a hitch.

It's been a long time since I've used robocopy, but it tells you something when you can see it can be done manually. I'm just not sure if the compression attribute is one that's carried over with the copyall switch. I would tend to think not.

It may be, that if the destination file already exists, and it's compressed, the new copy will also be compressed.

sibbil said:

It's been a long time since I've used robocopy, but it tells you something when you can see it can be done manually. I'm just not sure if the compression attribute is one that's carried over with the copyall switch. I would tend to think not.

It may be, that if the destination file already exists, and it's compressed, the new copy will also be compressed.

Hmmm, I tried your suggestion which is rerunning my script when the file in the destination folder is already compressed and it seemed to work. My only concern is that when the script is finished the size of the file started big and then after a few seconds it gets smaller and smaller until ultimately it becomes the same size as the original (source) compressed file. Is this normal behavior? The file is just 512MB in size and 79.8MB in size in disk.

It may be uncompressing source, copying, then recompressing target. I know that's what happens when a copy/move is done across a network. Here's a pretty good article on it (compression is about 2/3 down):

How NTFS Works: Local File Systems

Hmmm, yeah. So this is the only temporary fix you can think of for my issue? :)

How about /copy:dat instead of /copy:at.

The reason I'm thinking to try that is the fact that in addition to the compressed attribute, there is more data stored in the file that relates to compression.

Kind of a shot in the dark, though.