Network clients/services recommendation?

Jan 19, 2026 Last reply: 5 months ago 15 Replies

My disappointment with NetSarang's "Xmanager Suite" has finally boiled over. Too many silly bugs. And, its obvious that they don't even have the underlying (decades old!) technology correct.



Their suite includes:



- X server



- lpd



- TELNET/SSH console



- FTP client



I can live without lpd as I can make those connections without need of an intermediary (esp if that would require a Windows host to be running!)



Any suggestions?



If *all* I needed was the ftp client, I would standardize on Beyond Compare (which I have heartily recommended to my colleagues). It has very few bugs and there are workarounds for them (albeit annoying).



I can use PuTTY for SSH/TELNET; not as nice of an interface but it seems very reliable.



The X server is the holdup. I'm using VNC to work around that but it complicates the clients' configuration.


Thanks! I'll have a look at the demo... All of the references to UN*X utilities has me questioning if they are Windows hosted or hosted under cygwin, etc.

Don Y snipped-for-privacy@foo.invalid wrote: |-----------------------------------------------------------| |"- TELNET/SSH console | |- FTP client | | | |[. . .] | | | |I can use PuTTY for SSH/TELNET; not as nice of an interface| |but it seems very reliable." | |-----------------------------------------------------------|

I use PuTTY a lot without a problem. A recent version of Microsoft Windows has its own SSh implementation. I do not use it a lot.

I do not use FTP a lot on new versions of Windows. Even old versions of Windows used to come with their own implementations. Corrupted big files were risks, but probably more because big downloads via FTP (instead of e.g. SFTP or BitTorrent) are risky than because of Microsoft ineptness. Wget supports FTP, but I do not use it a lot for FTP to Windows.

Apple MacOS comes with an SSh client.

(S.

formatting link
fuer Kontaktdaten!)

I don't rely on MS for any "legacy" protocols. Their UI is (deliberately?) crippled to hide capabilities of the underlying filesystem, etc. (filename case sensitivity, MAXPATH, SMB issues with huge numbers of transfers).

You can use other tools to work around these -- but, when you return to the Windows GUI, you're screwed! (How do I access ReadMe when README, readme and ReAdMe all coexist in the same context?)

MS has issues trying to transfer large numbers of files via SMB. And, MAXPATHLEN issues.

So, if you want to confine yourself solely to the MS world, you *might* be able to avoid them (try unzipping a file with a/really/long/internal/path/name/to/a/specific/file to a folder that is/located/pretty/far/down/in/the/file/system.

PuTTY works though has a bit "dated" interface. The fact that each session is a separate window is, IMO, a win. Other clients want to use MDI -- which sucks if you want to exploit lots of screen space to see multiple sessions concurrently.

NCDware was my go-to X server in ages past. The NetSarang product is "adequate" and manages to coexist with my triple headed workstations without complaining.

The FTP product was the killer. It would become unresponsive (just the GUI side; transfers kept running). It would reconnect a disconnected session and forget to reinvoke all of the options that were in effect from the disconnected session (BIN being the most consequential). At times, it would just "stop" and act as if it was still running. etc.

I don't want to fight my tools -- they are supposed to work for me!

Beyond Compare is a workaround but not the ideal solution (for file transfer).

Don Y snipped-for-privacy@foo.invalid wrote: |-------------------------------------------------------------------| |"MS has issues trying to transfer large numbers of files via SMB. | |And, MAXPATHLEN issues. | | | |So, if you want to confine yourself solely to the MS world, | |you *might* be able to avoid them (try unzipping a file | |with a/really/long/internal/path/name/to/a/specific/file to | |a folder that is/located/pretty/far/down/in/the/file/system." | |-------------------------------------------------------------------|

Even cutting and pasting in Windows Explorer from C:\ to D:\ failed where the paths differed only by their drives letters (i.e. their paths are equally long). Windows Explorer reports for a directory on D:

- "Size: 2.51 GB [. . .] [. . .] Contains: 14,824 Files, 253 Folders". Such a D:-drive directory came to be on this D: drive by ordering Windows Explorer to cut and paste from this C: drive, but Windows Explorer buggily left many files behind on this C: drive

- "Size: 96.6 MB [. . .] [. . .] Contains: 1,190 Files, 59 Folders" despite copying to D: at least some of what remains on C: - e.g. D:\ailt_liom\Press-Ombudsman_paper\5u_iarratas_de_2023\Comments.txt is a perfect copy of C:\ailt_liom\Press-Ombudsman_paper\5u_iarratas_de_2023\Comments.txt

- Microsoft is bad but thank goodness it did not delete before copying!

Remarkably though, maybe Windows Explorer succeeded to copy everything but failed to delete originals, as only 1 subdirectory thereof remains on C: and Windows Explorer reported for it: "Size: 96.6 MB [. . .] Contains: 1,190 Files, 58 Folders" and reports for its D: counterpart: "Size 96.9 MB [. . .] [. . .] Contains: 1,191 Files". Dir/s/b and FC report that the D: version has D:\ailt_liom\Press-Ombudsman_paper\5u_iarratas_de_2023\submission-to-statutory-review-of-the-defamation-act-december-2016.pdf and that no counterpart is on the C: version. This missing filename has a length of only 125 characters.

|---------------------------------------------------------------------| |"I don't want to fight my tools -- they are supposed to work for me!"| |---------------------------------------------------------------------| Correct. (S.

formatting link
fuer Kontaktdaten!)

I'm not sure what you're trying to do but I use PuTTY for command line and

formatting link
for file access over various protocols.

The maligned Xmanager suite includes an X server (used to access my *BSD and Solaris boxen), graphical FTP client (so I can copy from one file/FTP/NFS/SMB server to another file/FTP/NFS/SMB server), telnet/ssh client (though MDI) and lpd service (usually only needed for oddball devices as I try to set up native interfaces on the UN*X boxen).

IO tend to move LARGE groups of files -- large in number and in size. E.g., I've moved 12T in the past several days.

Doing so, a server often closes the control connection while moving data so the client has to reopen the connection and REASSERT THE SAME OPTIONS that were previously in effect. Otherwise, it's APPEARANCE of continuing is illusory -- subsequent transfers aren't done under the same conditions as earlier ones.

Or, the UI will become unresponsive (perhaps a single-threaded implementation with upcalls to the GUI and when running balls out, not enough time to service the interface AND the GUI?

Or, it will act like it is still moving data and I can visibly see the server(s) are idle.

I.e., it's a s***ty piece of code.

Given that the TELNET/SSH client is also less desireable than e.g., PuTTY, the only thing the "suite" had going for it was lpd -- which isn't particularly useful to me.

[Suites tend to integrate things -- I could initiate a file transfer from within a TELNET session, etc.]

Beyond Compare gives me a graphical FTP client as a side-effect of its normal functionality. (and, seems to do so reliably -- one of the most well-crafter examples of a multithreaded desktop application that I've encountered!)

But, that's *all* it gives me (in terms of the needs addressed above)

wget and other command line tools are annoying to use as they require scripting -- something I don't mess with on Windows platforms as there is little value to THAT skillset.

And, rsync on a windows client would be ineffective. How would it store a local copy of makefile, Makefile and ClassX::Method5.cpp? You can come up with substitutions -- but, then tools can't correlate "THIS" with "that"

Eschew Windows.

For file transfers have a look at sftp. It looks like ftp but works much better in most situations. John

I don't need the secure aspect as the network isn't routed.

The issues tend to be more on a macro usage level. E.g., wanting to grab multiple files, entire subdirectories, move from the file system to an SMB share, FTP server to ANOTHER FTP server, etc.

And, not encounter name mangling or other implementation artifacts along the way.

E.g., UTF-8 vs UTF-16, path length limitations, name collisions due to case insensitivity /in the client/, etc.

Presently, I use some tool -- then sort out what it did wrong, afterwards. And, do manual fixups. Did ALL of the files get transferred? Did any of their names get mangled in the process? Were timestamps preserved? etc.

E.g., "client-side" is not "client–side", despite what your eyes may tell you.

There are too many different techniques I have to use to get the results that I want.

# cd /foo; tar cpf - baz | (cd /bar; tar xpf - )

Does it contain any UTF-16 characters /anywhere in the path/?

What's annoying is the filesystem supports things that their standard tools (and API?) seem to not address.

E.g., I can create file- and path-names that Explorer can't access. So, it's a defect in Explorer.

Try copying a share with a few million files to another. Watch to see how throughput drops precipitously! "Gee, can I restart from a convenient place where it left off?"

Ever notice how file sizes use different conventions based on the app that is revealing that information? A 0B file may appear as "1K" (that's a significant difference from 0!) Or, MiB in some places and MB in another? Or, "off by one" on size (rounding convention)?

# du -s *

rsync is the ticket.

Cheers

Phil Hobbs

Don Y snipped-for-privacy@foo.invalid wrote: |-----------------------------------------------------------------| |"Does it contain any UTF-16 characters /anywhere in the path/?" | |-----------------------------------------------------------------|

Dear Don Y,

No. This path is purely ASCII. I tend to choose only ASCII filenames for pratical reasons, because alas disasters are much easier with non-ASCII filenames.

|-----------------------------------------------------------------| |"Try copying a share with a few million files to another. Watch | |to see how throughput drops precipitously! "Gee, can I restart | |from a convenient place where it left off?"" | |-----------------------------------------------------------------|

Alas.

|------------------------------------------------------------------| |"Ever notice how file sizes use different conventions based on the| |app that is revealing that information? [. . .]" | |------------------------------------------------------------------|

Yes. (S.

formatting link
fuer Kontaktdaten!)

(s.b. MobaXterm)

So far, this LOOKS like a good deal! I am having some trouble sorting out what's where (and the right click menu seems like it missed a lot of opportunities at utility -- but, there's still a lot of digging that I have to do so there may be a setting, somewhere...)

It's nice that you can "disconnect" sessions from the MDI. It would be nice if they defaulted to that form of presentation.

Thanks, again, for the pointer! I'm about to hammer the FTP client to see how well it fares...

(sigh) No, it's as bad (if not worse).

It sure seems like folks just wrap a GUI around a legacy, single-threaded application without thinking about the consequences.

GUI ftp client -- which FTP features do you need? Filezilla did most of everything I ever wanted, but only has a fraction of the capabilities of FTP itself. For example I don't think it supports third party transfers.

Alternatively winfsp is a thing, dounno how well it works but it should allow treating ftp servers like network drives.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required