While testing one backup strategy I run accross a problem. I copied some test files from one folder to another and noticed that Directory Opus changed the date of last modification of one file to "now" after copy. See the image - it's the "blue.txt" file that Opus modified. The other file ("green.txt") was copied without any modification.
I tried this procedure in Windows Explorer and it copied both files without any problem. It didn´t altered the date. Again, see the image.
Do you have any idea as to why it happens? I checked the file but didn't see anything unusal. I'm going to ivestigate it further though.
Thanks in advance for replies.
Is this repeatable? What if you try Explorer first and then Opus, and then try them in the opposite order?
It could be the tunnelling "feature" of NTFS where if you delete a file and then create a new file with the same name shortly afterwards, the new file inherits the old one's information.
Which method are you using to copy the files? Drag & drop, toolbar button, copy & paste, or something else? If it's a toolbar button, does it just run the standard Copy command on its own or has it been modified?
Thanks a lot for reply, Leo.
I have tried your suggestion but it doesn't matter whether I use WE or DO first to copy the file.
I have the "Preserve the timestamps of copied files" turned on.
The bottom line is that copying the file via Opus' copy command alters it. It doesn't matter if I use drag and drop, Ctrl+c and Ctrl+v or Copy button inside Opus. If I use some third party copying utility (like Total Copy) inside Opus it copies the file without problem, just like Win. Explorer.
Anyway in the past this file had some text in Comment field and maybe a Description but it shouldn't matter. I deleted the comment and turned off the support for Description in Opus'preferences just to be sure but this didn't affect anything.
Thanks a lot for running the test.
When I downloaded the file myself I wasn't able to reproduce it either. So it seems that the thing that caused the problem didn't "survive" the transfer to or from rapidshare.
By the way when I look at your screenshot I see that the blue.txt file you downloaded from rapidshare has the original modification date and time (7.1.2010 23:07:54) whereas the modification date and time of the very same file I downloaded off rapidshare got changed to "now" on my system. And it doesn't have anything to do with Opus (I had shut down the Opus and tested it first only in W. Explorer). But I noticed that this is common because it happened with any other file. So I wonder how you managed to download the blue.txt file off rapidshare with the original date and time of modification preserved.
Anyway spotting this problem is a bit tricky because if you don't look for it you don't notice it. I think almost noone checks the modification dates of files after every copy operation.
OK, that explains everything .
I uploaded the same file (see attachment) but this time I packed it to .rar archive which preserves the creation/modification/last access time of files if you enable this option. And indeed this time I was able to reproduce the problem on my system. I uplodaded the .rar file, downloaded it and extracted it from the archive. When I copied the file in Opus, the operation changed the modification date/time to "now".
So you if you have time and feel like it you can try it. I appreciate your help.
It requires Win Rar though or I guess any rar extractor should do. This time you should be able to get the file with original modification date and time (7.1.2010 23:07:54) right off the bat without need to change it.
I live in Czech Republic. The timezone is GMT +1 hour.
I use Windows XP SP3 (Czech localization).
You weren't able to reproduce the copy issue or you you weren't able to extract the file from the archive with original modification date/time (7.1.2010 23:07:54) preserved?
I can't reproduce it either. 7z preserved the modification date/time from your .rar. Like Leo I reproduced your folder structure exactly to be sure.
You don't have any antivirus program running which may have intercepted the copy, checked the file and modified the date ? That's the only thing that comes to mind for me.
Thanks a lot guys for testing. You didn´t have to recreate the same folder structure though. This copy issue is not dependent on the source, destination or the folder structure above.
I hope this testing is not costing you a lot of time.
I guess the antivirus doesn't affect the file. The file copies fine in Windows Explorer while avast is running. Anyway I turned off the resident shield and tried to copy the file via Opus' copy command and the issue the problem is still there.
I guess I should mention the version of Opus. Mine is 9.5.0.0.3565.x86.
Maybe I should try to update it. I just noticed in leo's signature, that new version is available.
Thanks for the tip, Jon. That's a good idea. However I am rookie when it comes to deciphering the Process Monitor log. I haven't used this utility before. I am now trying to figure out from the log what went wrong. I noticed "Buffer overflow" and "Name not found" in the Result column. Do you want me to upload the .PML log file for you?
(When recording the data I turned on only Show File System Activity, targeted the Opus window (using the Include Process From Window button), cleared the display, turned on the capturing of events, switched to Opus, copied the file, switched back to Process Monitor, turned off capturing of events and saved the log to .PML file.)
You can probably narrow it down more by using a filter to only report on the file in question. And you shouldn't restrict it to Opus only, because there's a good chance it's not Opus doing it.
It might have made more sense if the window had been big enough to see the full data for the SetBasicInformationFile call, since this is presumably what is setting the file date
The log shows that Opus is setting the LastWriteTime to 7.1.2010 23:07:54 which, from your screenshot, is the correct time. So I don't know why it's being changed after that unless it's the NTFS tunnelling feature that Leo originally suggested.
.