Backing up files using Robocopy

[kevindd992002]

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.

 

[F5ing]

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).

 

[kevindd992002]

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.

 

[F5ing]

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.

 

[kevindd992002]

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.

 

[F5ing]

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.

 

[kevindd992002]

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.

 

[F5ing]

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

 

[kevindd992002]

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

 

[F5ing]

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.

 

[kevindd992002]

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

Same thing. /copy:dat is the default syntax that robocopy will use if you don't specify any /copy string.

 

[F5ing]

Well, true, but your command line is specifying not to use the default.

Edit: nevermind, I just reread your first post specifying that's what you originally tried.

 

[kevindd992002]

Well, true, but your command line is specifying not to use the default.

Edit: nevermind, I just reread your first post specifying that's what you originally tried.

Yup. So I'm guess I'm stuck here

 

[F5ing]

Did you try /copyall?

 

[kevindd992002]

Yeah.

 

[F5ing]

Well, the best I can come up with right now is just turning on compression for the destination folder plus contents. I know that's not what you're looking for. If you really want that file compressed and none of the others, maybe think about separate folders, one compressed and the other not.

 

[kevindd992002]

Well, the best I can come up with right now is just turning on compression for the destination folder plus contents. I know that's not what you're looking for. If you really want that file compressed and none of the others, maybe think about separate folders, one compressed and the other not.

Yeah I guess. Thanks for the time

 

[F5ing]

You're welcome. I'm curious about this now, if I find or think of something I'll post back...

 

[kevindd992002]

Right. Thanks again!

 

[F5ing]

Well, got a little news. Not good however. There are quite a few forum posts out there that complain about this exact "shortcoming" of robocopy. Responses all say for the poster to check out third party software. No one mentioned an app they knew that worked. Couple hours ago I had run across a program that claimed it could do it. I think it was Second Copy, not freeware, and don't have any idea of the cost. I've heard of it before, but I've no clue as to whether it's reliable or not...