back to article Windows Server robocopy to gain auto-compression ahead of big file moves

Microsoft has teased some coming-real-soon-now features for future editions of Windows Server. The software behemoth last week staged a low-key online “Windows Server Summit” that concluded with principal program manager Ned Pyle showing off features including auto-compression of files before they’re moved. Pyle first …

  1. Mr Dogshit

    a low-key online “Windows Server Summit”

    So low-key, I didn't know about it.

  2. Stuart Castle Silver badge

    Potentially a nice addition to an already useful utility. However, how effective will the compression be? After all, a lot of file formats are already compressed, and files that are already compressed, tend not to compress well, in my experience.

    1. poohbear

      Did you enable the "Must try harder" option?

    2. IGotOut Silver badge

      Your right, in fact sometimes compressing a compressed file can make it bigger!

      1. Ochib

        Unless you use middle out compression

    3. johnfbw

      Of course they may have put in a precheck to see if the file was compressed in a known format - only a couple extra lines of code to save a bit of CPU (not sure how much bigger the already compressed files get - guessing not enough to significantly hurt the network)

  3. katrinab Silver badge

    I would much rather see support for rsync

    Windows already has ssh support, so we are half-way there. You can do rsync on the Linux subsystem, with various degrees of success. But it doesn't really work between two Windows systems.

    1. needmorehare

      I would rather see all of Windows Server added to Windows 10 Pro. Then people would be able to see the glorious benefits of the server tools on a properly updated OS. It appears they've started doing this already with Windows 10 20H2, as it now has Remote Desktop Services installable and licensable if you install the feature with DISM. I hope more is around the corner.

      Windows services (in the main) use standardised RPC protocols for remote administration, have very stable codebases and are infinitely easier to script/automate consistently (thanks, Jeffrey Snover) and run as reliably as their Linux equivalents in my experience. The only downside I see is that they're less flexible in configuration and seem to lack the sweet spot in logging for debugging rare edge cases.

      However, a complete feature set would make available:

      * AppLocker as an extra layer of anti-malware protection

      * Proper IPSec, SSTP and IKEv2 VPN server support

      * Proper IIS with FTP, HTTPS and SMTP (no connection limits)

      * PCI-E passthrough on Hyper-V (Discrete Device Assignment)

      * DHCP, DNS servers for replacing crappy home router implementations

      * Decent PXE/TFTP services (Windows Deployment Services)

      * DFS Replication/Namespaces (compresses and syncs better than rsync)

      * Server Resource Management (RAM limiting and scheduler policies for apps)

      * NTFS/ReFS Deduplication (gives you a situation on par with ZFS)

      * RD Gateway (to make existing RDP more secure over the Intermet)

      ...and much much more

  4. Anonymous Coward
    Anonymous Coward

    Remember doing that with the DOS based PK-ZIP - compressing a ZIP file, just to see what would happen.

    Ended up with a file larger than the original uncompressed file!

    1. Roland6 Silver badge

      I remember doing autocompression on SunOS back in the 1980's so it looks like its only taken MS 30+ years to implement something that is blindingly obvious - hence will most probably have submitted a patent application...

  5. Yet Another Anonymous coward Silver badge

    SMB over tcp

    Any reason why you can't do SMB over TCP 'to the cloud' isn't the whole point of TCP not caring what you are sending or where?

    1. 9Rune5 Silver badge

      Re: SMB over tcp

      Well, one reason for that...

      From the article:

      Using QUIC will make SMB ready for use in mobile and edge applications, Pyle said. has this to say:

      Another goal of the QUIC system was to improve performance during network-switch events, like what happens when a user of a mobile device moves from a local WiFi hotspot to a mobile network. When this occurs on TCP, a lengthy process starts where every existing connection times out one-by-one and is then re-established on demand. To solve this problem, QUIC includes a connection identifier which uniquely identifies the connection to the server regardless of source. This allows the connection to be re-established simply by sending a packet, which always contains this ID, as the original connection ID will still be valid even if the user's IP address changes.

  6. ChrisElvidge

    Windows not-Server

    I hope that the robocopy in Desktop gets the same treatment.

  7. Anonymous Coward
    Anonymous Coward


    Hopefully there will be a don't compress switch

    1. Nick Ryan Silver badge

      Re: Robocopy

      Similarly a "just try and compress it regardless" switch too.

  8. Michael Wojcik Silver badge

    the future of what now?

    SMB over QUIC is the future of distributed systems

    Good god, I hope not. SMB is a horrible, horrible protocol, and QUIC is only slightly better than the typical "let's reinvent TCP using UDP" attempt.

    QUIC solves certain problems, true; that's because it's optimized for different use cases than TCP is. That doesn't mean everything should be switched from TCP to QUIC. And it especially doesn't mean that we should prolong the life of dreadful rubbish like SMB by promoting QUIC as a transport for it.

    And, of course, the vast majority of distributed systems don't use SMB, because they're not interested in anything SMB does. Remote filesystems are a niche application, statistically, when the whole of IT is considered.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021