Searching \ for '[OT] Reliable Windows to Windows File Transfer ove' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=reliable+windows
Search entire site for: 'Reliable Windows to Windows File Transfer ove'.

Exact match. Not showing close matches.
PICList Thread
'[OT] Reliable Windows to Windows File Transfer ove'
2009\07\30@195446 by solarwind

picon face
Hey all!

I'm looking for a way to transfer large files/large quantities of
files from one Windows machine to another Windows machine over LAN.
The system has to be reliable (detect errors in the files and
re-transfer broken parts of files). Something like rsync, but easier
to set up and use. I looked at Filezilla client/server system (FTP)
but some of the files would have errors in them when on the
destination machine. I don't know why, but they do. Perhaps due to the
high speed (10 Megabytes/s)?

Anyway, what would you guys suggest?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\07\30@211109 by Adam Field

flavicon
face
> I'm looking for a way to transfer large files/large quantities of
> files from one Windows machine to another Windows machine over LAN.
> The system has to be reliable (detect errors in the files and
> re-transfer broken parts of files). Something like rsync, but easier
> to set up and use. I looked at Filezilla client/server system (FTP)
> but some of the files would have errors in them when on the
> destination machine. I don't know why, but they do. Perhaps due to the
> high speed (10 Megabytes/s)?
>
> Anyway, what would you guys suggest?

Have you tried smb/cifs? You know, the built in windows networking
sharing protocol? It may be a bit slower in certain conditions than
other protocols, but I've never had it corrupt any transfer ever. Then
again, I've never had any problems with FTP on a local network
(filezilla included). What kind of network runs 10 megabytes/second?
Do you mean 100 megabit? Common ethernet is 10/100/1000 megabits per
second. In any case, all three have been superbly reliable for me over
the years, even with ancient 10 base hubs where the collision light
would go solid the whole transfer.

If not rsync is the way to go (or perhaps sftp, but that'll be SLOW
with the encryption overhead usually), maybe search for a windows gui
for rsync? Or use a cygwin environment so you can have a bash shell.
I'm sure you could schedule rsync backups with the windows task
scheduler.

2009\07\30@220708 by Jesse Lackey

flavicon
face
Hummm, it is pretty hard to imagine the errors are due to network
hardware issues, at the ethernet packet level there is CRC checking and
whatnot to detect such problems.  Could the classic "ascii vs. binary"
ftp transfer mode be wrong?  It is possible that ftp is in "ascii" mode,
whereby CR/LF are being changed to keep ascii text files (which they
aren't, in your case) formatted properly for the target machine.

Alternatively, you could look at "CopyTo synchronizer", which I use to
keep my lappy and main desktop system in sync.  Not free but cheap.

J


solarwind wrote:
{Quote hidden}

2009\07\30@222833 by solarwind

picon face
On Thu, Jul 30, 2009 at 9:11 PM, Adam Field<spam_OUTadamTakeThisOuTspambadtech.org> wrote:
> Have you tried smb/cifs? You know, the built in windows networking
> sharing protocol? It may be a bit slower in certain conditions than
> other protocols, but I've never had it corrupt any transfer ever. Then
> again, I've never had any problems with FTP on a local network
> (filezilla included). What kind of network runs 10 megabytes/second?
> Do you mean 100 megabit? Common ethernet is 10/100/1000 megabits per
> second. In any case, all three have been superbly reliable for me over
> the years, even with ancient 10 base hubs where the collision light
> would go solid the whole transfer.

I'll give SMB/CIFS a go. Also reminded me of NFS (very solid when I
used it). My network is a gigabit network and I limited my machines to
10 megabytes/s (the two windows computers, anyway).

> If not rsync is the way to go (or perhaps sftp, but that'll be SLOW
> with the encryption overhead usually), maybe search for a windows gui
> for rsync? Or use a cygwin environment so you can have a bash shell.
> I'm sure you could schedule rsync backups with the windows task
> scheduler.

I want to avoid cygwin/mingw or rsync. But I guess I'll have to do it
if there's no other option.

Thanks.

2009\07\30@222936 by solarwind

picon face
On Thu, Jul 30, 2009 at 10:07 PM, Jesse Lackey<.....jsl-mlKILLspamspam@spam@celestialaudio.com> wrote:
> Hummm, it is pretty hard to imagine the errors are due to network
> hardware issues, at the ethernet packet level there is CRC checking and
> whatnot to detect such problems.  Could the classic "ascii vs. binary"
> ftp transfer mode be wrong?  It is possible that ftp is in "ascii" mode,
> whereby CR/LF are being changed to keep ascii text files (which they
> aren't, in your case) formatted properly for the target machine.

I'll check that out. Thanks.

2009\07\31@122420 by Robin D. Bussell

flavicon
face
Try Robocopy:
http://en.wikipedia.org/wiki/Robocopy

watch out though as I've been told it will happily replicate the wrong
way if you tell it to and thus trash the source rather than destination.

Cheers,
    Robin.

{Original Message removed}

2009\07\31@153905 by Richard Benfield

flavicon
face
Microsoft's free synctoy will do exactly what you want

http://www.microsoft.com/downloads/details.aspx?FamilyID=c26efa36-98e0-4ee9-a7c5-98d0592d8c52&DisplayLang=en

solarwind wrote:
{Quote hidden}

2009\07\31@231658 by solarwind

picon face
On Fri, Jul 31, 2009 at 3:38 PM, Richard Benfield<piclistspamKILLspam450se.co.uk> wrote:
> Microsoft's free synctoy will do exactly what you want
>
> http://www.microsoft.com/downloads/details.aspx?FamilyID=c26efa36-98e0-4ee9-a7c5-98d0592d8c52&DisplayLang=en

Thanks, all. I'll check all these options out.


'[OT] Reliable Windows to Windows File Transfer ove'
2009\08\01@014319 by Lucas
flavicon
face

Original link: http://en.wikipedia.org/wiki/SyncToy

There are a couple of problems reported about SyncToy in the above page:

Certain file types (including JPEG images and WMA audio files) become
corrupted when synchronised to some Network Attached Storage (NAS) devices.
The corruption happens to the files stored on the NAS itself. This is
something that affects SyncToy 2.0 and according to an employee, Microsoft
has identified the problem and is working to provide a fix as of 12 March
2009.

The current version of SyncToy, release 2.0, does not operate reliably under
Windows XP. The system will hang up or slow down dramatically even under
simple synchronizing operations. This has been reported to Microsoft but has
not been resolved as late as June 2009. Forum discussions often recommend
that users install an older version of SyncToy for use in XP systems.
Unfortunately, there are no older versions available for download from the
Microsoft Website.

{Original Message removed}

2009\08\01@081923 by John Ward

flavicon
face
try robocopy

On Sat, Aug 1, 2009 at 7:41 AM, Lucas<.....lucasKILLspamspam.....rosstech.ca> wrote:
>
> Original link: http://en.wikipedia.org/wiki/SyncToy
>
> There are a couple of problems reported about SyncToy in the above page:
>
> Certain file types (including JPEG images and WMA audio files) become
> corrupted when synchronised to some Network Attached Storage (NAS) devices.
> The corruption happens to the files stored on the NAS itself. This is
> something that affects SyncToy 2.0 and according to an employee, Microsoft
> has identified the problem and is working to provide a fix as of 12 March
> 2009.
>
> The current version of SyncToy, release 2.0, does not operate reliably under
> Windows XP. The system will hang up or slow down dramatically even under
> simple synchronizing operations. This has been reported to Microsoft but has
> not been resolved as late as June 2009. Forum discussions often recommend
> that users install an older version of SyncToy for use in XP systems.
> Unfortunately, there are no older versions available for download from the
> Microsoft Website.
>
> {Original Message removed}

2009\08\01@111923 by Gerhard Fiedler

picon face
Adam Field wrote:

>> I'm looking for a way to transfer large files/large quantities of
>> files from one Windows machine to another Windows machine over LAN.
>> The system has to be reliable (detect errors in the files and
>> re-transfer broken parts of files). Something like rsync, but easier
>> to set up and use. I looked at Filezilla client/server system (FTP)
>> but some of the files would have errors in them when on the
>> destination machine. I don't know why, but they do. Perhaps due to
>> the high speed (10 Megabytes/s)?
>>
>> Anyway, what would you guys suggest?
>
> [...] Then again, I've never had any problems with FTP on a local
> network (filezilla included).

Agreed. The thing is, if FTP messed up the files, you have a problem
that you need to fix before trying anything else. Either you messed up
and used the wrong FTP file type (ASCII vs Binary), or there's something
wrong with your FTP installation (server or client), or your TCP/IP
stack or your network is severely messed up. I'd vouch for the first;
seems to be the most likely.

The error rate that gets past the TCP/IP stack on a LAN should be very
close to 0. And FTP is good enough to splice the pieces together, again
with an error rate very close to 0.

Running FTP a lot over VPN connections (arguably worse than plain
Internet, and definitely much worse than LAN), I don't think I've ever
had an error in an FTP transfer. Aborted transfers yes, but no corrupted
files.

Gerhard

2009\08\01@182434 by peter green

flavicon
face

> Agreed. The thing is, if FTP messed up the files, you have a problem
> that you need to fix before trying anything else. Either you messed up
> and used the wrong FTP file type (ASCII vs Binary), or there's something
> wrong with your FTP installation (server or client), or your TCP/IP
> stack or your network is severely messed up. I'd vouch for the first;
> seems to be the most likely.
>
> The error rate that gets past the TCP/IP stack on a LAN should be very
> close to 0. And FTP is good enough to splice the pieces together, again
> with an error rate very close to 0.
>  
FTP does not do any checking of it's own, if an error gets past the
TCP/IP stack undetected (very unlikely on a lan) then FTP won't catch it.

2009\08\01@203048 by Gerhard Fiedler

picon face
peter green wrote:

>> Agreed. The thing is, if FTP messed up the files, you have a problem
>> that you need to fix before trying anything else. Either you messed
>> up and used the wrong FTP file type (ASCII vs Binary), or there's
>> something wrong with your FTP installation (server or client), or
>> your TCP/IP stack or your network is severely messed up. I'd vouch
>> for the first; seems to be the most likely.
>>
>> The error rate that gets past the TCP/IP stack on a LAN should be
>> very close to 0. And FTP is good enough to splice the pieces
>> together, again with an error rate very close to 0.
>
> FTP does not do any checking of it's own, if an error gets past the
> TCP/IP stack undetected (very unlikely on a lan) then FTP won't catch
> it.

Right... but if the connection has a hiccup and is interrupted, it will
splice the parts together (if server and client support this).

FWIW, the anatomy of an FTP connection:
<http://www.eventhelix.com/RealtimeMantra/Networking/FTP.pdf>

Gerhard

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...