copy file question

[adit39]

My application currently uses "copy file" to backup data files to external HD. I use "copy file" to restore the files from external HD to original folder, but the file dates and times change from original backup date and time to current date and time. Can anyone tell me why and offer a solution to preserve original backup date and time when I restore the backed up files? If I use "copy file" to restore the data from the command window, original backup dates and times are preserved as expected.
Thank you

 

[Dan Freeman]

You can't really mess with the innards of VFP's internal commands, but you can mess with the result.

Use Foxtouch() inside foxtools.fll to change the file's datetime stamp to anything you want it to be. See

http://support.microsoft.com/kb/114949

 

[Olaf Doschke]

I can't reproduce that, but if that happens, the question is, if that depends on the file system (eg you copy from NTFS to FAT and back) or if it's really foxpro. You can at least try three other methods to copy: DOS XCOPY command, automating Scripting.Filesystemobject and Windows API CopyFile() function.

If all these show the same file datetime behaviour its more likely, it has to do with the file systems of the internal and external HD.

Bye, Olaf.

 

[Olaf Doschke]

To add: I tried to reproduce the change of file datetime using VFPs COPY TO command, and though I waited several seconds before each copy, the file was restored with it's original datetime as FDATE(file,1). But I tried on the same HDD with just a separate backup folder.

Not sure why, but something about the file systems was different and could be a reason the fdate changes.

Bye, Olaf.

 

[adit39]

Thanks for the replies!
Olaf, my procedure uses COPY FILE, not COPY TO fot both backup and restore. Everything works well but I would prefer to retain original dates on the files which were backed up when we restore, if necessary. The original date is retained on the backup media, which in this case is external HD. To add to the mystery, CUST.FPT file date does NOT change but the CUST.DBF and CUST.CDX files DO change when restored back to original location. Strange??
Tony

 

[Mike Lewis]

Tony,

I've been trying to reproduce this problem, but cannot do so.

I use COPY FILE to copy a DBF, CDX and FPT to an external drive. I then delete the files from the original location, then use COPY FILE to copy them back. The original dates are retained in every case - as I would expect.

This suggests that there is something unusual about your system, although I'm at a loss to know what it is.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Sorry, I meant COPY FILE, it's COPY FILE TO, but of course the short for it is COPY FILE, COPY TO only works for DBFs opened as source. No, I copied a file via COPY FILE, trying to reproduce. Later this day, I may add my test code.

Is the external drive by chance a NAS device? These have their internal filesystems, typically Linux, even though the expose the drive as if it was an NTFS share, that can play a role and you might be able to change NAS settings.

Bye, Olaf.

 

[Olaf Doschke]

Oh, and by the way: I tried if file dates would be preserved, if you'd ZIP files instead of COPY TO, but that also has mixed results. So far I got newer fdates using vfpcompression.fll to unzip. PErhaps really FoxTouch is your life saver, also see thread184-1709311 T%hat would mean, you'd have to store the file date seperately. And you may also need to use ATTRIB to change the Archive Attribute back to original.

Coming to think of all this stuff, perhaps Robocopy would be a good tool for backup&restore, you can easily adjust it to any needs, you can even let it mirror from a source to a destination, which makes the destination folder an exact mirror including file dates and attributes, and limits all operations to the ones necessary, eg it will only copy new or modified files and also delete deleted files.

Bye, Olaf.

 

[adit39]

Thanks Mike and Olaf.
I just checked the drives and both are NTFS. I don't mind living with current issue as restores are so rare but I just thought the date issue is strange.

 

[adit39]

Also, if I copy the files from command prompt, no problem, dates are retained.

 

[Olaf Doschke]

Yes, you said so, I did write a PRG and executed that. But I may try, if compiling as an EXE makes the difference, maybe there is a difference between VFP9.EXE and VFP9R.DLL behaviour (Within the IDE you don't make use of VFP9R.DLL, but of VFP9.EXE, a built EXE makes use of VFP9R.DLL, so there may be a diff in the COPY FILE command causing that).

Bye, Olaf.

 

[Mike Lewis]

I also tried it both from the command window and from a PRG (although I didn't try building an EXE).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[adit39]

Mystery solved!! EXE didn't behave differently but Mike's response included the word "deleted" and that was the difference. If original backed up files are deleted prior to Restore, original date/time of backed up files are preserved when restored.
Thanks,
Tony

 

[Mike Lewis]

I must say I would never have thought that. I can't quite see why it should be so. But it's good that you have solved it.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Well, the mysteries of the file system. I have made another observation, which I make use of for quite some while:
I have done a small picture batch resizing utility for a website using gdiplusx and it writes files out with all uppercase file names. If I stroe them into another folder and then copy them back to the original, where files with the original capitalisation still exist, the files are overwritten, but the original capitalisation is kept. So it seems Windows is no erasing/writing the new file, but it is overwriting the file content resusing the old filename entry in the TOC (table of contents).

I haven't inspected what happens to file times, but I think they are updated. In my case the good side effect is I don't have to find out how to keep the file name capitalisation, I can get it back with this last step. What's interesting is, this only works, when copying the new files over the old ones, if I instead MOVE the new files, they are moved inclluding their all upper case file names.

And also in my tests of COPY TO I erased the file before copying, therefore I also didn't find the behavior you saw.

So finally, let's see what happens, if you erase vs not erase:

If !directory("d:\temp")
   MkDir d:\temp
EndIf

If !directory("d:\temp\backup")
   MkDir d:\temp\backup
EndIf 

* first pass, no problem while erasing destination folder files
? "1st pass"
Cd d:\temp
Erase d:\temp\test.txt
* create file
StrToFile("test","d:\temp\test.txt")
? Fdate("d:\temp\test.txt",1)

Erase d:\temp\backup\test.txt
Wait '' timeout 3
* backup
Copy File d:\temp\test.txt to d:\temp\backup\test.txt

Erase d:\temp\test.txt
Wait '' timeout 3
* restore
Copy File d:\temp\backup\test.txt to d:\temp\test.txt
? Fdate("d:\temp\test.txt",1)

* second pass, no erasing now, just suppessing safety warning via SET SAFETY OFF
? "2nd pass"
Set Safety Off

Cd d:\temp
? Fdate("d:\temp\test.txt",1)

Wait '' timeout 3
* backup
Copy File d:\temp\test.txt to d:\temp\backup\test.txt

Wait '' timeout 3
* restore
Copy File d:\temp\backup\test.txt to d:\temp\test.txt
? Fdate("d:\temp\test.txt",1)

Set Safety On

Actually, for me that makes no difference. The first file creation datetime is preserved all the time, no matter if erasing destination folder files before copying or not.

I still assume this is not VFP but file system behavior.

Bye, Olaf.