 |
|
|
|
|
|
|
|
|
This guy has written no articles and posted a single message ever and it is a vote of 1 for me.
Perhaps I should feel privileged.
|
|
|
|
|
|
|
Hi Pascal,
Exactly what I was looking for! Simple, easy to use and fast. Before I found sync I was using a vbs script. It worked fine but was mega slow.
Thanks for a great tool!
Tonny.
|
|
|
|
|
|
|
Hi i'm new to the code project and new to programing. I havent done much in the way programming but am finding the code project a really useful place. Your project is very interset but i was looking to convert it to c# as a class when reading through the code there doesnt seem to be an equivilant to DirectCast. Any ideas. thanks
|
|
|
|
|
|
|
DirectCast in C# is a simple cast.
In VB
Dim I As Object = 123
Dim J As Integer = DirectCast(I, Integer)
In C#
object i = 123;
int j = (int)i;
|
|
|
|
|
|
|
iwant to make a program to copy file to cd_writer or usb and i don't know how can i work with it help me please
syria first
|
|
|
|
|
|
|
I would be happy to help you if I can
However, you should describe with more details what you want to do.
Is it a Console program or a program with a user interface?
Do you want to copy always the same files or is it something that the user has to choose?
Sync is already a program to copy and synchronize files. You will have to ask more clearly what you really need.
|
|
|
|
|
|
|
Robocopy, as its own documentation states, may not behave as expected on a non-english OS. That's a major drawback for me. This one is the little gem I needed and was looking for. Mercy Pascal!
Manuel JD Alves
|
|
|
|
|
|
|
For a lot of data (about 2GB, about 8000 files) when all files are unchanged, so don't need to be copied, across a 100M ethernet, Sync takes about 45 secs and Robocopy takes about 7 (seven!) secs.
I haven't done a comparison of times when files are being copied, maybe Sync is better then.
I used the /S /XN switches with Robocopy, so wasn't deleting files (which can be done using /PURGE). It's Robocopy from the Windows 2003 Server ResKit, a free download from Microborg.
But the thought behind Sync is appreciated anyway 
|
|
|
|
|
|
|
When I wrote Sync, I did not know about any other utility doing the same.
If I had known about it I would probably have used it.
Now it is written, I suppose it can be used integrated into your own programs. As I said it is not rocket science, for a problem this simple you would think that the solution should be trivial. Reading the interest this program raises, I realize this problem is not that trivial.
I don't have robocopy in my XP, Where do you get it from ?
|
|
|
|
|
|
|
|
|
|
Robocopy with the mirror option should do pretty much the same thing. It is also flexible enough to deal with some of the unique situations you might run across
robocopy.exe source destination /MIR
The above command will "mirror" the source to the destination - deleting files in the destination that no longer appear in the source and only updating files that have been changed. There are 50+ options to robocopy which allow fairly fine grained control over how it works. There is a version of Robocopy for modern operating systems (XP/2003) -the kbase article mentioned before only refers to an NT version that may not be as mature as the more recent versions.
This URL contains a list of all the options for the modern version and may link to a download location: http://www.ss64.com/nt/robocopyXP.html[^]
-Dave
|
|
|
|
|
|
|
duh!! Robocop cost $$$$
This is free AND open source.
|
|
|
|
|
|
|
Not true. I was able to find it and download it from Microsoft without cost. It comes with a resource kit (which does cost $$ - and is what you are probably refering to). But you can also download it and many of the other resource kit tools directly from Microsoft's website.
|
|
|
|
|
|
|
Here is the link of Windows Server 2003 Resource Kit Tools
http://go.microsoft.com/fwlink/?LinkId=4544
|
|
|
|
|
|
|
It's totally free, AFAIK
Ravi Ambros Wallau
Send a mail to raviaw_at_gmail.com
|
|
|
|
|
|
|
I'm glad to see any improvements to the XCOPY command. I sure will be experimenting with SYNC. Thanks
I know this isn't exactly on topic but it is very closely related so I thought I'd pass my experience along.
I have several customers that wanted to use CD and DVD +/-RW media for backup purposes on their entry level fileservers. Most drive companies claim you can do exactly that in their documentation. Well, it depends on how you are doing your backups.
XCOPY is touted as being the first choice in backing up folders to safeguard your data. The concept is something like this. Write a batch file containing a series of XCOPY commands that will copy your data to the destination media. Setup a scheduled task to launch the batch file at the appropriate time. Pop in a formatted CD or DVD +/-RW disk in the drive and you are good to go.
Sounds easy enough until your customers start complaining about unusable disks after a few weeks that have been used only a few times. Upon examining the disk you may see a white band burned into the media near the hub of the disk. What's going on here? Well, it's the choice of format and media that is causing the damaged disks to be over burned and worn-out.
The RW format/media is only good for 1000 writes (a fact not expressed with great effort by drive manufacturers). XCOPY updates the directory/FAT countless times during a backup of containing tens of thousands of files and subfolders. The result is the area of the disk containing the directory structure will get written so many times that it exceeds the design limits of the RW media and the disk becomes unusable. Flash Pen drives also suffer from limited write ability so you are not out of the woods with these either.
What are some solutions? One way is use a backup utility that will copy the files all-at-once thus reducing the writes to the directory structure. PKZIP and other will allow entire folder structures to be compressed into a single file.
The other method is to choose a media that was designed specifically for large numbers of writes. Removable hard disks are one obvious choice. The problem here is the cost of the media is the cost of an entire hard drive plus caddy. (15 or 20 hard drives for entire backup cycle of daily, weekly and monthly full backups). The next more practical choice is DVD-RAM media. DVD-RAM is spec'ed for 100,000 writes and was originally designed for use in the national archives as backup/archive media. Current prices are $5-$10 each for DVD-RAM but when you consider that the RW media may be failing within a few backups, the DVD-RAM media becomes easier to justify.
I know what some of you are thinking about now. "Why haven't I heard about this before?" Just like me early on, I hadn't tried it and assumed what I was hearing was the truth. But having seen rapidly increasing stacks of damaged media I got to the truth.
I now recommend removable hard drives or NAS if the budget allows. But the best tradeoff for price vs. reliability is DVD-RAM. Tape drives are another choice but the media can be much more costly and from my experience not reliable enough.
The next time you go to your local store and try to buy DVD-RAM media, you will likely be surprised how few are stocked as compared to RW media. This in part is a reflection of how few people are actually backing up with XCOPY and RAM media. It is more likely a reflection of how few people are actually backing up their data. Some of course are using programs designed to write all-at-once to do backups. But scheduled backup utilities almost never come with RW drives.
Hope you find this useful and save yourself some grief.
|
|
|
|
|
|
|
I got a problem with the date of last write.
Using FILE.COPY it add up to 2 seconds to the last modified date.
It looks like it happen when the source and destination folders are in different type of partitions.
It occurs at least when source is NTFS and destinations is WIN32.
I would appreciate have an inkling of what could be wrong.
|
|
|
|
|
|
|
|
|
|
This is what I call a documented answer... !
So far I empirically found that a file with a last modification date of 10:00:00.000 AM, will end up copied with a date time between 10:00:00.000 AM and 10:00:01.999 AM.
In other words, most of the time the files have precisely the same modification time but sometime up to two seconds were added (but never substracted).
Now if I read your M$ article, the date of modification is what they call write time.
It seems to confirm my assumption of 2 seconds.
It doesn't say which way it is though.
Do you think I should revert the default back to 2 second in both ways (either added or substracted) ?
|
|
|
|
|
|
|
|
|
|
This is because fat stores times to the nearest two seconds.
John
|
|
|
|
|
|
|
It would be much better to write a reverse delta algorithm.
Just compare the file and update the bytes. It would be twice as fact. although I seriously doubt it would be pure c# to get the needed performance.StringBuilder might get it done, but I doubt it.
Nick
I'm not an expert yet, but I play one at work. Yeah and here too.
|
|
|
|
|
|
|
Too hard.
It was taking half an hour with DELETE + XCOPY
It is now taking less than a minute.
This is definitely fast enough for now.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin