When I moved from XP to Vista(64) on my desktop, I bought the Belkin Easy Transfer Cable for Vista (F5U258ea). Besides the new installation, the cable has worked perfectly even for normal file transfer with my laptop, also running Vista(64). Thanks TC for the advise on http://www.ghisler.com/cables/ !
Now I have installed Win7(64) on the desktop, but I still have Vista(64) on my laptop. The cable still works for data transfers, even though it seems to have occasional problems with the CRC of some files, which fail to download (I don't wnow if this has anything to do with the cable at all).
Before moving to Win7(64) even on the laptop, I would like to know the answer to the following question (I thoroughly searched the net and the TC forums, but I didn't find it, or maybe missed it ):
Will the same cable work for normal, everyday data transfer between machines both running Win7(64), or do I need the Belkin cable specifically made for Win7 (F5U279ea)?
In short: does the software inbedded in the cable affect/interfere with the data beeing transferred or does it limit itself to the "uppgrading bit" between OSs?
Thanks in advance for an answer and thanks to all the gurus on the forums for a magnificent work!
... does it limit itself to the "uppgrading bit" between OSs?
No, the the cable works independent of the OS.
It just needs the drivers on both sides, which are compatible for Vista/7/8/8.1.
I think, the naming "Belkin Easy Transfer Cable for Vista" is just related to the point of time, the cable is manufactured.
At this time Vista was the latest OS and nobody knows anything about others.
Will the same cable work for normal, everyday data transfer between machines both running Win7(64), or do I need the Belkin cable specifically made for Win7 (F5U279ea)?
No problem. As sqa_wizard said, the name "for vista" is just a relict from the time this technology was introduced by MS.
The cable still works for data transfers, even though it seems to have occasional problems with the CRC of some files, which fail to download (I don't wnow if this has anything to do with the cable at all)
It could also be that one of the USB ports has some problems, or that a RC-transmitter (cellphone?) was placed near the cable.
But as long as such glitches are detected by CRC-checks there should be no danger for your data.
PS: Last week i'd used a similar cable (LogiLink) to do a synchronize directory data compare between two win7(x64) machines. In this case the client and server TC just calculate the local checksums and transfers only the checksums over the cable.
This compare via (USB) port connection was even faster than comparing the data via a Gigabit Ethernet connection.
Copying data may be slower than Gigabit Ethernet (easy transfer cables are only USB 2.0 with a maximum transfer speed about 20-30 MByte/s) but in most cases faster than a Wifi connection or a 100Mbit Ethernet cable connection.
I got to borrow a laptop running Win7 Starter 32 and I'll do some cross testing with TC and my two systems (Vista64 and 7 Home Premium 64). I'll be back with the results as soon as I'm through with it.
I believe this could be of some general interest for the people out there that like myself wonder why these "easy transfer cables" are only mentioned on the web in connection with upgrading OSs and never, as far as I can see, as common everyday tools for moving files between computers.
Well, here come the results of my tests, for what they're worth.
In my original post I wrote: "Besides the new installation, the cable has worked perfectly even for normal file transfer with my laptop". Wrong, my bad.
I had got that impression because I had previously transferred almost exclusively data, and in small amounts. Now I know better.
The Belkin Vista cable seems to have a dislike for some types of files when transferring from Vista to Win7, and even between different versions of Win7, at least in the 3 systems I have been able to cross-test, running on 3 different machines. The OS-environments where tested both as client and as servers. The copy operations were run on a number of files of various types and sizes, picked up at random.
The hardware/software specs are reported at the end of the post.
The filetypes I tested that didn't cause any trouble are:
bin, bmp, cat, cfg, chm, cmd, com, dat, dll, inf, ini, jpeg, lnk, msi, ocx, pif, png, sys, tpl, txt, wav, vbs, xml... The files that invariably generated CRC-errors when transferred in the "WRONG DIRECTION" are:
avi, cpl, exe, gif, jpg, log, mp3, msu, pdf, pnf, ttf, wmv, zip...
Which is surprising to say the least. Belkin states clearly that the cable is intended to only transfer personal documents and not programs. The "Easy Transfer Function" included in the OS certainly takes care of that, but it seems that even the chip in the transfer device must have been somehow programmed to block some system-critic files, possibly to have people buy a new cable with every new OS. Still, it has no problems with files that are obviously needed to run programs, while it stops multimedia files like avi, jpg, gif, mp3, etc. Weird.
Attempts to download "problematic" files in the "WRONG DIRECTION" will result in partial download and failure, although with sporadic success to complete after repeated attempts: >> F5 Copy >> "Resume Download" (8 attempts necessary to copy the file tcm851ax64, size: 4.626.886).
A somewhat random behaviour seems to show that small-size "problematic" files (>~70.000 Kb) may manage to download at first or second attempt.
On top of this, some quirks have shown up regarding server-operation:
Navigation (double click on dir or root):
- Random fail to open dir or go back to root, with or without frozen & blank server panel. Message on server: CRC error: Retrying! > LIST FAILED
Reread or Navigation buttons (\ ..) lead back to root, (random) success with repeated attempts
F6 Move button:
Random frozen & blank server panel. Message on server: CRC error: Retrying! > LIST FAILED
Reread or Navigation Buttons (\ ..) lead back to root, rename however shows successful.
The observed (mis)behaviour is consistent through all tests, so I do not think it can be explained with machine-specific settings or hardware/software problems of the USB ports. Which ports I by the way took care to change now and then.
I entertained for a while the suspicion that the culprit could be the FTPs transmission speed because of the following message on server:
Alas, this is not mentioned anywhere, least of all on the TC site, and I could find no relevant setting anywhere.
Unless some very smart guy (there are quite a few around on these forums) comes with a workaround or explanation, my conclusion is that with the Belkin Vista cable: - Vista64 can't communicate properly with Win7 HomePremium64 and Win7 Starter32
- Win7 Starter32 can't communicate properly with Win7 HomePremium64.
All of which would explain why there's no mention on the web of the use of these cables as ordinary tools to transfer/manage files between computers. Under hours of hunting I have come across only commercials or requests of info regarding the compatiblity of this or that FOR UPGRADING operative systems.
On the other hand, it does NOT explain the information given in this regard on the TC site (that we all know to be a serious place, look at the number of my personal license in the signature, please) which presents the universal operation of the Belkins cables as matter-of-fact: "Please do yourself a favor and order one of these if you want to use a cable with Total Commander".
Question: What am I missing?
Very grateful in advance for any answer.
==================================================================
SYSTEMS
==================================================================
HP Pavillion - Vista64
Sony Vaio - 7 HomePremium64
Asus Eee PC - 7 Starter32
CABLE
Belkin Easy Transfer Cable for Vista (F5U258ea)
PROG
Total Commander (x64) 8.51a
---------------------------------------------------------------------
DRIVERS INSTALLED BY OS
---------------------------------------------------------------------
DEVICE MANAGER
>>> Transfer Cable Devices
>>> Belkin USB Easy Transfer Cable
>>> Driver Details: C:\Windows\system32\DRIVERS\winusb.sys
2Artist,
As all your test machines seems to be notebooks:
Can you try the same tests when all notebooks are connected to power (not battery powered) and ensure that the power saving options are set at least to "balanced" or "high performance".
And please pay attention which end of the cable is connected to which pc.
The transfer cable has a small chip in the middle which must be powered over one side of the usb cable.
Maybe the pc on the connection side which powered this chip turns the usb-port in energy saving mode when it detects less activity.
The HP Pavillion is a desktop and the laptops have been connected to power all the time under testing. On top of that, they are configured to never go into energy saving mode.
By the way, could you tell me the denomination (or art.nr.) of the LogiLink cable you mentioned? I searched the brand name but I couldn't see any transfer cables among the hundreds of LogiLink produtcts.
I have used a Belkin Easy Transfer Cable for Vista (F5U258) for many years (in fact I was tester of the cable for Ghisler when he implementer it's use in TC) and I have never had those problems. I don't have a Vista PC but I use the cable between Windows XP, Windows 7 SP1 x64 Home Edition and Windows 8.1 x 64 Home.
I have just testet all possible combinations of the tre OS'es copying the totalcmd.exe file in both directions and it all worked fine.
The only little problem I have is that Windows 8.1 don't notify me when I plug the cable in (it only plays the "device-connected" sound), And the cabele is not listet in Windows 8.1's Autoplay list as it is in Windows 7.
Note, my cable doesn't have "ea" in the end of the product code as your have - F5U258ea - maybe that makes a difference?
License #524 (1994)
Danish Total Commander Translator
TC 11.55rc4 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1393a
TC 3.60b4 on Android 6, 13, 14 TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
Well, it may make the difference, but it's unlikely.
Please note that the Vista cable shown on http://www.ghisler.com/cables/
as tested 100% compatible has exactly the product code F5U258ea.
That's why I bought it in the first place.
That picture is actually of my cable! - I guess I got the product code from the box it was shipped in back then - on the back of my cable it only shows F5U258.
Maybe you could try and test both your computers to a third computer - there could be something wrong with one of yours.
License #524 (1994)
Danish Total Commander Translator
TC 11.55rc4 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1393a
TC 3.60b4 on Android 6, 13, 14 TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
Belkin states clearly that the cable is intended to only transfer personal documents and not programs.
Actually in terms of transfer files only, not complete installations (incl. registry entries).
Copying files is a transfer of bytes, no matter which purpose it has.
I just have just a cheap cable (7 €) Delock Vista USB Link Adapter.
Used with WinXP <=> Win7 Pro and Win7 Pro <=> Win7 Pro.
I never had any CRC-problems ...
Artist wrote:By the way, could you tell me the denomination (or art.nr.) of the LogiLink cable you mentioned? I searched the brand name but I couldn't see any transfer cables among the hundreds of LogiLink produtcts.
But i doubt that you can get a new one (maybe a used one on ebay).
I guess all of these cables do have more or less the same chip (8032 MCU) and are using the same protocol to communicate with the windows driver.
Could you try your test with reverse connected cable ("PC-A<->cable-A <-> cable-B<->PC-B" and "PC-A<->cable-B <-> cable-A<->PC-B").
If the result of this two tests is exactly contrary it may be that your cable has a (hardware-)problem transfering data in one direction.
In this case i would try to contact your seller and RMA/replace the cable.
Like petermad i'd used this cable (and a second one from Delock) since 2010 with several computers (XP home+prof, Vista x86 home+ultimate, Windows 7x64 ultimate / netbook, notebook, desktops, workstations) and never got such errors.
Maybe there is an antivirus program on the server side interfering with the file transfer? It can delay writes by several seconds, which can cause a timeout in the transfer protocol.
2ghisler (Author Emeritus)
I ran the tests shutting down both antivirus and firewall on both sides.
Nope. No difference.
2petermad
I have checked the back of my cable now, and it says only F5U258.
We have the same cable, except your works...
2HolgerK
Thanks for the suggestion, it seems to have identified at least part of the problem.
I ran the same test twice inverting the cable ends, and yes, I got contrary results. I marked one side, ran more tests and it seems that one specific end of the cable must be connected to the specific transfer's source machine, no matter if client or server. As the same cable works both ways for others it would mean, as you say, that my cable has a hardware problem transferring in one direction. Except for one thing. Such a hardware problem would produce failures for all types of files, all kinds of transfers in one direction. In this case some filetypes, always the same no matter the size, always get trough without CRC-errors, while some others, always the same no matter the size, just refuse to transfer. As sqa_wizard wrote, "Copying files is a transfer of bytes" no matter their purpose, and file endings should make no difference. But they do in this case. This is the one thing my tests have proved beyond doubt.
I bought my cable, new, on eBay (couldn't find it locally) about one year ago, following the advice on the TC site. Your cables seem to be much older than that. Maybe Belkin changed something in the chip for some market reason? At the moment this is the only explanation I can think of.
All the same, the cable goes. Too late for a RMA, I'll try to get something else, LogiLink, Delock or other, as long as it isn't Belkin.
TC does its own CRC checking of transferred blocks, and re-sends blocks in case of CRC errors. You probably get too many CRC errors, so TC gives up and reports the error.
):
