11 ms·

After years of working exclusively on Windows, I took a job that required me to build file management, except now, on macOS and Linux (along with Windows). All

After years of working exclusively on Windows, I took a job that required me to build file management, except now, on macOS and Linux (along with Windows). All I can say is, this article is the tip of the ice berg on Windows I/O weirdness. You really don't realize how strange it is until you are actively comparing it to an equivalent implementation on the two other competing operating systems day-to-day. Each of them has their quirks, but I think Windows takes the cake for "out there" hacks you can do to get things running. I sometimes like to ponder what the business case behind all of them was, then I Google it and find the real reasons are wilder than most ideas I can imagine. Fun stuff!

ChuckNorris89 3y ago
From my experience as an EE, working with serial ports is much nicer on Windows (COM1, COM2, etc.) than on Linux where serial ports are abstracted to files like /dev/ttyACM0 and has a lot more gotchas. PowerShell is also quite a powerful alternative to Bash/Mingw, although it came out much later. Windows might do some things differently than UNIX-like OSs, but it does them really well.
- klysm 3y ago
  I’ve found the assignment of com ports in windows really annoying
- mikub 3y ago
  I just started with using serial ports on windows while doing some Raspberry Pico hobby projects. Something that I find strange is that every new device gets assigned a new comport, I mean let's say I do this for a while one day I will have a comport 100, 200 and so on. Is that right, or does it somehow reset the comports?
  - zwieback 3y ago
    That's how it works and generally it's to the user's advantage. We often set specific parameters based on the device's serial number so getting the same COM port is nice, sometimes the devices are so simple that you cannot query its serial number. Sometimes I'll do a "blank slate" and delete all my accumulated COM ports in Device Manager (need to enable "Show Hidden Devices").
- wolletd 3y ago
  Technically, COM1, COM2 etc. are filenames as well. They are just special in that they are available everywhere. That's why you are not allowed to create any file named COM1 or such. But it's a DOS relic. Actually, Windows has a "Win32 Device Namespace" under "\\.\", which is something like /dev/ in Unixoids. COM1 is actually \\.\COM1: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-device-namespaces https://learn.microsoft.com/en-us/windows/win32/fileio/namin...
  - riffic 3y ago
    it's a CP/M relic of i'm not mistaken https://en.wikipedia.org/wiki/CP/M https://en.wikipedia.org/wiki/CP/M
    - blooalien 3y ago
      Wow! There's an operating system I ain't heard tell of in a good long while. That's the very first OS I used in a professional context. Got me my first computer store job (in my late "teens") on a CP/M system.
  - pixl97 3y ago
    I deal with software that processes files on a Windows system... loves to break when people on other OS's subnet AUX, PRN, COM, File:Name, and tons of other unacceptable names (like 'file '). I'm glad our new releases work on Linux and we don't have to deal with that crap in 99.99% of cases now.
- throwaway09223 3y ago
  I've done quite a bit of work with serial ports on Windows, Linux and other unixes. I've also written a serial device driver. Your comment is very confusing to me. The serial ports are abstracted to a file on Windows just like on unixes - the file is actually discussed in the above article: \COM1 Maybe you're talking about the old days where you would just outb 0x3f8? The modern interfaces are actually fairly similar.
  - zwieback 3y ago
    0x3f8 IRQ4, 0x2f8 IRQ3 - still hardcoded in my brain 30yrs on!
    - blooalien 3y ago
      My "burned in" code snippet is "call -151" from Apple ][+ days, to drop to the built-in 6502 (dis)assembler/debugger.
      - zwieback 3y ago
        MONZ I spent a lot of time reading the disassmbly listing in the back of the manual to see what happens when I jump to the monitor.
        blooalien 3y ago
        Remember typing in entire programs from magazines and computer manuals and saving them to cassette tape or floppy disc? That was "the good ol' days" for sure… :)
  - kevin_thibedeau 3y ago
    There is also the persistent problem of USB serial adapters being assigned incremental numbers until they're in double digits that many tools don't let you select from their GUI. So you have to go in and manually purge those devices to get back to sane numbering.
- scoutt 3y ago
  COM1 = CreateFile("COM1", ...) => Nice! COM9 = CreateFile("COM9", ...) => Nice! COM10 = CreateFile("\\\\.\\COM10", ...) => NOT nice!
  - Kwpolska 3y ago
    How often do you end up with 10 COM ports?
    - zwieback 3y ago
      We do all the time. In industrial automation COM ports are still shockingly popular, although it's usually the USB emulated variety. On a lot of our development and on some of our production tools we end up with COM20 or COM30, not because we have that many running at one time but because over time we've plugged in that many distinct devices. Nowadays most drivers will assign COM(n+1) when they see a device with a new serial number.
      - connicpu 3y ago
        UART is available on nearly every microcontroller under the sun, and USB<->UART serial chips are super cheap, so it makes complete sense to me that'd become the defacto system for interfacing the automation controller with a computer
        InitialLastName 3y ago
        Even beyond that, USB is available on many microcontrollers, a USB CDC device is dead simple to implement, the drivers are baked into every modern OS, and all the software developers operating at that layer already know how to interact with text streams. Add in the ease of debugging when you can just manually send/receive ASCII to operate a device, and you've got the makings of a standard practice.
    - rogerbinns 3y ago
      If you use USB dongles for serial adapters, then each path through USB is assigned a different COM number when you plug it in. For example if you plug into USB controller 2, port 3 which goes to a hub, and then you plug into port 2 that gets a number. Now plug the same thing into a different port and it will get another COM number. Under the hood this is because the USB devices do not have the (optional) unique serial number (or in some cases they all get the same serial number). https://devblogs.microsoft.com/oldnewthing/20041110-00/?p=37343 https://devblogs.microsoft.com/oldnewthing/20041110-00/?p=37...
- JohnFen 3y ago
  Interesting. I very much prefer working with serial ports under Linux than Windows. It's more straightforward and easier to engage in fine control.
  - BrandoElFollito 3y ago
    So do I, I find the addressing more consistent, too. It used to be completely predictable when I was working with drivers on 1994 (patching the code), then less predictable when hardware for more diverse, and predictable again (or at least "always the same") with UUIDs. It was always amateur/hobby dev or sysadmin so I may have had the wrong impression.
- qalmakka 3y ago
  COM ports on Windows are crap nowadays due to how crappy USB to serial adapters have become. I've seen Windows reassigning different COM names to the same device every single time it was unplugged due to it "remembering" what COM port was used previously. Needless to say, that was an anti-feature if there ever was one.
  - dfox 3y ago
    Windows tries to keep a long term identity of all of the device instances that it knows about (and in the idela world assign the same COM port numer to the same physical serial adapter). For USB this is supposed to be done by combination of VID, PID and serial number in device descriptor. But even early on there was a lot devices that had the serial number empty and thus Windows came up with some heuristics about when this method is unreliable and switches to identifying the device by its physical position on the USB bus. The whole mechanism is well intentioned, but in the end probably somewhat misguided because it is not exactly reliable and has surprising consequences even if it were reliable. As a side note: on modern Windows NT implementations the so called "registry bloat" is non-issue (anyone who tells your otherwise is trying to sell you something), but keeping list of every device that was ever plugged into the computer in there is somewhat ridiculous.
    - mmis1000 3y ago
      It also do this for monitor or usb/bluetooth earphones. So you end up get earphone(2), monitor(2) even you never have a second one. The only way to fix it is delete the hidden device in device monitor and rename it back in monitor/audio manager. It's really a confusing thing to me that the script I use to change sound output and leveling suddenly didn't work after a bios/mobo software/whatever windows update and noticing the device have an appended (2).
      - yndoendo 3y ago
        And this is why I hate Windows in an industry automation environment. Dislike having to troubleshoot why that USB NIC or Serial device being destroyed by plugging it into another port. Had to write a PowerShell script for the USB NIC issue to reapply NIC settings with a reboot. Also, always locking an open file is repulsive. Other OSs allow for renaming an open file. Not Windows! Thumbs.db being locked because File Explorer keeps the file open / locked preventing deleting an empty folder and wastes so much time waiting for Windows to unlock the file. You have to pay me to use Windows!
rightbyte 3y ago
> All I can say is, this article is the tip of the ice berg on Windows I/O weirdness. You really don't realize how strange it is until In one way it is beautiful. "Laid cards lies", you know. Don't mess with the user for your conception of Agile Clean Extreme Code (tm). Each stupid design decision is forever. Windows .bat files win the awfulness and quirkyness contest with sh with a razor thin margin. And both are awesome.
- Kwpolska 3y ago
  Windows has PowerShell these days, and it is actually usable and not at all awful (if a little quirky) compared to bat files.
  - 2devnull 3y ago
    “Powershell(tm): Not Entirely Awful (if a little quirky)!” Seems worth investing a lot time into given Microsoft’s history of not rug pulling developers.
    - connicpu 3y ago
      The first release was 16 years ago and they're still making new releases of it so I'd say it's definitely here to stay ;)
      - WorldMaker 3y ago
        Also it is MIT-licensed open source today: https://github.com/PowerShell/PowerShell https://github.com/PowerShell/PowerShell
        thrixton 3y ago
        And cross platform: https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.3 https://learn.microsoft.com/en-us/powershell/scripting/insta... Not that it’s a particularly compelling feature on Linux with the standard offering, but it’s a good option for cross platform scripts at times, particularly running in docker.
conductr 3y ago
I’m not familiar with inner workings, but simply moving files feels odd in Windows compared to macOS. If it’s a big lift in terms of data size or file/folder counts it’s most obvious but it feels like Windows literally copies the files into memory, then rewrites them on disk or something similar that has results in negative performance and a long running cut/copy/paste dialog box. I’ve had some of these run for hours on decent hardware (SSD, etc) for what I consider small datasets (couple GB). It’s been a major Windows gripe of mine for years now. Meanwhile macOS appears to just change an internal link to the data that’s already written on disk. As such, it’s usually so very fast compared to Windows.
- armarr 3y ago
  That's likely to be due to the NTFS file system. Another piece of legacy Windows drags along
- ripley12 3y ago
  Been a while since I looked at the details, but Explorer's file management is generally slow compared to what you can do with the actual Win32 APIs.
- fencepost 3y ago
  A lot of this depends on whether you're crossing devices. If you think of drive letters as mount points it may make more sense - if you're moving between mountable filesystems obviously a move has to be a copy-then-delete; if you're remaining on the same filesystem a move can typically be a rewriting of indexing information only with very limited data rewriting. One other thing that can be an issue particularly on NTFS with ACLs is that moving files typically retains their ownership and permissions, while copying files typically inherits the ownership and permissions of the destination. This can bite you if as an administrator you're moving data from one user's account to another because a move will leave the original owner still owning the files.
- WorldMaker 3y ago
  Windows File Explorer does a lot of extra work to get a sense of file sizes and other metadata to try to keep the UI looking fresh/interesting/useful to someone watching the job in real time. If you need to seriously move/copy lots of files or lots of data in Windows it is generally a good idea to use shell commands. Robocopy [1], especially, is one of the strongest tools you can learn on Windows. (It gets very close to being Windows' native rsync.) [1] https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy https://learn.microsoft.com/en-us/windows-server/administrat...
hilbert42 3y ago
"All I can say is, this article is the tip of the ice berg on Windows I/O weirdness." Well, then, is there a more detailed summary than this one that's accessible? This one looks very useful and I'll use it, but to make the point about more info it'd be nice to know how they differ across Windows versions. For example, I've never been sure about path length of 260 and file length of 255. I seem to recall these were a little different in earlier versions, f/l being 254 for instance. Can anyone clear that up for me? Incidentally, I hit the 255/260 limit regularly, it's damn nuisance when copying stops because the path is say 296 or 320, or more.
- ChrisSD 3y ago
  There are some APIs that have a lower limit than 260. But the limits can be bypassed using `\\?\` prefixed paths (except when using SetCurrentDirectory) or by enabling long paths https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later https://learn.microsoft.com/en-us/windows/win32/fileio/maxim...
  - arka2147483647 3y ago
    Windows.h defines MAX_PATH as 260. Many apps do something like char path[MAX_PATH] In that case, no amount of prefixing will help you, if random app enforces the limit.
    - hilbert42 3y ago
      "no amount of prefixing will help you, if random app enforces the limit" I've noticed that, it's partially the reason for my confusion (I didn't wake up for quite a while as I put it down to the different versions of Windows I was running on various machines). Other pains are caused by apps that still don't run Unicode and crash or stop copying when they encounter a non-ASCII character.
    - pjmlp 3y ago
      Yeah, old ones using raw Win32 calls, where developers haven't read anything beyond Petzold's book.
fsckboy 3y ago
"get-a-byte, get-a-byte, get-a-byte, byte, byte" - Dave Cutler https://retrocomputing.stackexchange.com/questions/14150/how-should-we-interpret-dave-cutlers-criticism-of-unix https://retrocomputing.stackexchange.com/questions/14150/how... >Windows I/O weirdness. You really don't realize how strange it is until you "can I get a wut... WUT?" - Developers, Developers, Developers ==== it's just hard for people today to understand what a revolution stdin and stdout was, full 8 bit but sticking with ASCII as much as possible. There was nothing about it that limited Unices from having whatever performant I/O underneath, but it gave programmers at the terminal the ability to get a lot done right from the command line. The web itself is an extension of stdin and stdout, and the subsequent encrusting of simple HTTP/HTML/et al standards with layer upon layer of goop that calls for binary blobs can be seen as the invasion of Cutlerian-like mentalities. It's sad that linux so successfully took over that all the people who we were happy to let use IIS and ASP and ActiveX had to come over to this side with their ideas. No idea of which is bad, but which together are incoherent. client server FTW, bring it back
- chasil 3y ago
  At least Windows paths are not as clunky as Cutler's prior operating system, VAX/VMS Version 1.00 21-AUG-1978 15:54. $ create/directory dm0:[foobar] $ set default dm0:[foobar] $ copy DM0:[SYSMGR]SYSTARTUP.COM example.txt $ dir/full DIRECTORY DM0:[FOOBAR] 21-APR-23 14:42 EXAMPLE.TXT;1 (615,2) 0./0. 21-APR-23 14:42 [1,4] [RWED,RWED,RWED,RE] TOTAL OF 0./0. BLOCKS IN 1. FILE
  - dhosek 3y ago
    I rather liked VMS conventions as it was immediately obvious what was the directory part of the path and what was the filename and the device. You could create virtual devices as well, so for example, with VMS TeX, I had TEX_ROOT defined to point to the root of the TeX distribution and you would have TEX_ROOT:[INPUTS] for the input directory, TEX_ROOT:[MF] for Metafont files, TEX_ROOT:[EXE] for executables, etc. and everything was logically arranged. CLD files were another wonderful thing where you could define your CLI interface in an external file and let the OS handle argument and option parsing for you.
tinus_hn 3y ago
It’s the flip side of the ‘we bent over backwards so SimCity runs’ coin. Even though Windows hasn’t supported programs out of this era since 64bit became the standard, it’s still held back by clinging on to the legacy. Because it doesn’t dare say ‘this is too old, run it in a VM’.

ChuckNorris89 3y ago

From my experience as an EE, working with serial ports is much nicer on Windows (COM1, COM2, etc.) than on Linux where serial ports are abstracted to files like /dev/ttyACM0 and has a lot more gotchas. PowerShell is also quite a powerful alternative to Bash/Mingw, although it came out much later. Windows might do some things differently than UNIX-like OSs, but it does them really well.

klysm 3y ago
I’ve found the assignment of com ports in windows really annoying
mikub 3y ago
I just started with using serial ports on windows while doing some Raspberry Pico hobby projects. Something that I find strange is that every new device gets assigned a new comport, I mean let's say I do this for a while one day I will have a comport 100, 200 and so on. Is that right, or does it somehow reset the comports?
- zwieback 3y ago
  That's how it works and generally it's to the user's advantage. We often set specific parameters based on the device's serial number so getting the same COM port is nice, sometimes the devices are so simple that you cannot query its serial number. Sometimes I'll do a "blank slate" and delete all my accumulated COM ports in Device Manager (need to enable "Show Hidden Devices").
wolletd 3y ago
Technically, COM1, COM2 etc. are filenames as well. They are just special in that they are available everywhere. That's why you are not allowed to create any file named COM1 or such. But it's a DOS relic. Actually, Windows has a "Win32 Device Namespace" under "\\.\", which is something like /dev/ in Unixoids. COM1 is actually \\.\COM1: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-device-namespaces https://learn.microsoft.com/en-us/windows/win32/fileio/namin...
- riffic 3y ago
  it's a CP/M relic of i'm not mistaken https://en.wikipedia.org/wiki/CP/M https://en.wikipedia.org/wiki/CP/M
  - blooalien 3y ago
    Wow! There's an operating system I ain't heard tell of in a good long while. That's the very first OS I used in a professional context. Got me my first computer store job (in my late "teens") on a CP/M system.
- pixl97 3y ago
  I deal with software that processes files on a Windows system... loves to break when people on other OS's subnet AUX, PRN, COM, File:Name, and tons of other unacceptable names (like 'file '). I'm glad our new releases work on Linux and we don't have to deal with that crap in 99.99% of cases now.
throwaway09223 3y ago
I've done quite a bit of work with serial ports on Windows, Linux and other unixes. I've also written a serial device driver. Your comment is very confusing to me. The serial ports are abstracted to a file on Windows just like on unixes - the file is actually discussed in the above article: \COM1 Maybe you're talking about the old days where you would just outb 0x3f8? The modern interfaces are actually fairly similar.
- zwieback 3y ago
  0x3f8 IRQ4, 0x2f8 IRQ3 - still hardcoded in my brain 30yrs on!
  - blooalien 3y ago
    My "burned in" code snippet is "call -151" from Apple ][+ days, to drop to the built-in 6502 (dis)assembler/debugger.
    - zwieback 3y ago
      MONZ I spent a lot of time reading the disassmbly listing in the back of the manual to see what happens when I jump to the monitor.
      - blooalien 3y ago
        Remember typing in entire programs from magazines and computer manuals and saving them to cassette tape or floppy disc? That was "the good ol' days" for sure… :)
- kevin_thibedeau 3y ago
  There is also the persistent problem of USB serial adapters being assigned incremental numbers until they're in double digits that many tools don't let you select from their GUI. So you have to go in and manually purge those devices to get back to sane numbering.
scoutt 3y ago
COM1 = CreateFile("COM1", ...) => Nice! COM9 = CreateFile("COM9", ...) => Nice! COM10 = CreateFile("\\\\.\\COM10", ...) => NOT nice!
- Kwpolska 3y ago
  How often do you end up with 10 COM ports?
  - zwieback 3y ago
    We do all the time. In industrial automation COM ports are still shockingly popular, although it's usually the USB emulated variety. On a lot of our development and on some of our production tools we end up with COM20 or COM30, not because we have that many running at one time but because over time we've plugged in that many distinct devices. Nowadays most drivers will assign COM(n+1) when they see a device with a new serial number.
    - connicpu 3y ago
      UART is available on nearly every microcontroller under the sun, and USB<->UART serial chips are super cheap, so it makes complete sense to me that'd become the defacto system for interfacing the automation controller with a computer
      - InitialLastName 3y ago
        Even beyond that, USB is available on many microcontrollers, a USB CDC device is dead simple to implement, the drivers are baked into every modern OS, and all the software developers operating at that layer already know how to interact with text streams. Add in the ease of debugging when you can just manually send/receive ASCII to operate a device, and you've got the makings of a standard practice.
  - rogerbinns 3y ago
    If you use USB dongles for serial adapters, then each path through USB is assigned a different COM number when you plug it in. For example if you plug into USB controller 2, port 3 which goes to a hub, and then you plug into port 2 that gets a number. Now plug the same thing into a different port and it will get another COM number. Under the hood this is because the USB devices do not have the (optional) unique serial number (or in some cases they all get the same serial number). https://devblogs.microsoft.com/oldnewthing/20041110-00/?p=37343 https://devblogs.microsoft.com/oldnewthing/20041110-00/?p=37...
JohnFen 3y ago
Interesting. I very much prefer working with serial ports under Linux than Windows. It's more straightforward and easier to engage in fine control.
- BrandoElFollito 3y ago
  So do I, I find the addressing more consistent, too. It used to be completely predictable when I was working with drivers on 1994 (patching the code), then less predictable when hardware for more diverse, and predictable again (or at least "always the same") with UUIDs. It was always amateur/hobby dev or sysadmin so I may have had the wrong impression.
qalmakka 3y ago
COM ports on Windows are crap nowadays due to how crappy USB to serial adapters have become. I've seen Windows reassigning different COM names to the same device every single time it was unplugged due to it "remembering" what COM port was used previously. Needless to say, that was an anti-feature if there ever was one.
- dfox 3y ago
  Windows tries to keep a long term identity of all of the device instances that it knows about (and in the idela world assign the same COM port numer to the same physical serial adapter). For USB this is supposed to be done by combination of VID, PID and serial number in device descriptor. But even early on there was a lot devices that had the serial number empty and thus Windows came up with some heuristics about when this method is unreliable and switches to identifying the device by its physical position on the USB bus. The whole mechanism is well intentioned, but in the end probably somewhat misguided because it is not exactly reliable and has surprising consequences even if it were reliable. As a side note: on modern Windows NT implementations the so called "registry bloat" is non-issue (anyone who tells your otherwise is trying to sell you something), but keeping list of every device that was ever plugged into the computer in there is somewhat ridiculous.
  - mmis1000 3y ago
    It also do this for monitor or usb/bluetooth earphones. So you end up get earphone(2), monitor(2) even you never have a second one. The only way to fix it is delete the hidden device in device monitor and rename it back in monitor/audio manager. It's really a confusing thing to me that the script I use to change sound output and leveling suddenly didn't work after a bios/mobo software/whatever windows update and noticing the device have an appended (2).
    - yndoendo 3y ago
      And this is why I hate Windows in an industry automation environment. Dislike having to troubleshoot why that USB NIC or Serial device being destroyed by plugging it into another port. Had to write a PowerShell script for the USB NIC issue to reapply NIC settings with a reboot. Also, always locking an open file is repulsive. Other OSs allow for renaming an open file. Not Windows! Thumbs.db being locked because File Explorer keeps the file open / locked preventing deleting an empty folder and wastes so much time waiting for Windows to unlock the file. You have to pay me to use Windows!

rightbyte 3y ago

> All I can say is, this article is the tip of the ice berg on Windows I/O weirdness. You really don't realize how strange it is until In one way it is beautiful. "Laid cards lies", you know. Don't mess with the user for your conception of Agile Clean Extreme Code (tm). Each stupid design decision is forever. Windows .bat files win the awfulness and quirkyness contest with sh with a razor thin margin. And both are awesome.

Kwpolska 3y ago
Windows has PowerShell these days, and it is actually usable and not at all awful (if a little quirky) compared to bat files.
- 2devnull 3y ago
  “Powershell(tm): Not Entirely Awful (if a little quirky)!” Seems worth investing a lot time into given Microsoft’s history of not rug pulling developers.
  - connicpu 3y ago
    The first release was 16 years ago and they're still making new releases of it so I'd say it's definitely here to stay ;)
    - WorldMaker 3y ago
      Also it is MIT-licensed open source today: https://github.com/PowerShell/PowerShell https://github.com/PowerShell/PowerShell
      - thrixton 3y ago
        And cross platform: https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.3 https://learn.microsoft.com/en-us/powershell/scripting/insta... Not that it’s a particularly compelling feature on Linux with the standard offering, but it’s a good option for cross platform scripts at times, particularly running in docker.

conductr 3y ago

I’m not familiar with inner workings, but simply moving files feels odd in Windows compared to macOS. If it’s a big lift in terms of data size or file/folder counts it’s most obvious but it feels like Windows literally copies the files into memory, then rewrites them on disk or something similar that has results in negative performance and a long running cut/copy/paste dialog box. I’ve had some of these run for hours on decent hardware (SSD, etc) for what I consider small datasets (couple GB). It’s been a major Windows gripe of mine for years now. Meanwhile macOS appears to just change an internal link to the data that’s already written on disk. As such, it’s usually so very fast compared to Windows.

armarr 3y ago
That's likely to be due to the NTFS file system. Another piece of legacy Windows drags along
ripley12 3y ago
Been a while since I looked at the details, but Explorer's file management is generally slow compared to what you can do with the actual Win32 APIs.
fencepost 3y ago
A lot of this depends on whether you're crossing devices. If you think of drive letters as mount points it may make more sense - if you're moving between mountable filesystems obviously a move has to be a copy-then-delete; if you're remaining on the same filesystem a move can typically be a rewriting of indexing information only with very limited data rewriting. One other thing that can be an issue particularly on NTFS with ACLs is that moving files typically retains their ownership and permissions, while copying files typically inherits the ownership and permissions of the destination. This can bite you if as an administrator you're moving data from one user's account to another because a move will leave the original owner still owning the files.
WorldMaker 3y ago
Windows File Explorer does a lot of extra work to get a sense of file sizes and other metadata to try to keep the UI looking fresh/interesting/useful to someone watching the job in real time. If you need to seriously move/copy lots of files or lots of data in Windows it is generally a good idea to use shell commands. Robocopy [1], especially, is one of the strongest tools you can learn on Windows. (It gets very close to being Windows' native rsync.) [1] https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy https://learn.microsoft.com/en-us/windows-server/administrat...

hilbert42 3y ago

"All I can say is, this article is the tip of the ice berg on Windows I/O weirdness." Well, then, is there a more detailed summary than this one that's accessible? This one looks very useful and I'll use it, but to make the point about more info it'd be nice to know how they differ across Windows versions. For example, I've never been sure about path length of 260 and file length of 255. I seem to recall these were a little different in earlier versions, f/l being 254 for instance. Can anyone clear that up for me? Incidentally, I hit the 255/260 limit regularly, it's damn nuisance when copying stops because the path is say 296 or 320, or more.

ChrisSD 3y ago
There are some APIs that have a lower limit than 260. But the limits can be bypassed using `\\?\` prefixed paths (except when using SetCurrentDirectory) or by enabling long paths https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later https://learn.microsoft.com/en-us/windows/win32/fileio/maxim...
- arka2147483647 3y ago
  Windows.h defines MAX_PATH as 260. Many apps do something like char path[MAX_PATH] In that case, no amount of prefixing will help you, if random app enforces the limit.
  - hilbert42 3y ago
    "no amount of prefixing will help you, if random app enforces the limit" I've noticed that, it's partially the reason for my confusion (I didn't wake up for quite a while as I put it down to the different versions of Windows I was running on various machines). Other pains are caused by apps that still don't run Unicode and crash or stop copying when they encounter a non-ASCII character.
  - pjmlp 3y ago
    Yeah, old ones using raw Win32 calls, where developers haven't read anything beyond Petzold's book.

fsckboy 3y ago

"get-a-byte, get-a-byte, get-a-byte, byte, byte" - Dave Cutler https://retrocomputing.stackexchange.com/questions/14150/how-should-we-interpret-dave-cutlers-criticism-of-unix https://retrocomputing.stackexchange.com/questions/14150/how... >Windows I/O weirdness. You really don't realize how strange it is until you "can I get a wut... WUT?" - Developers, Developers, Developers ==== it's just hard for people today to understand what a revolution stdin and stdout was, full 8 bit but sticking with ASCII as much as possible. There was nothing about it that limited Unices from having whatever performant I/O underneath, but it gave programmers at the terminal the ability to get a lot done right from the command line. The web itself is an extension of stdin and stdout, and the subsequent encrusting of simple HTTP/HTML/et al standards with layer upon layer of goop that calls for binary blobs can be seen as the invasion of Cutlerian-like mentalities. It's sad that linux so successfully took over that all the people who we were happy to let use IIS and ASP and ActiveX had to come over to this side with their ideas. No idea of which is bad, but which together are incoherent. client server FTW, bring it back

chasil 3y ago
At least Windows paths are not as clunky as Cutler's prior operating system, VAX/VMS Version 1.00 21-AUG-1978 15:54. $ create/directory dm0:[foobar] $ set default dm0:[foobar] $ copy DM0:[SYSMGR]SYSTARTUP.COM example.txt $ dir/full DIRECTORY DM0:[FOOBAR] 21-APR-23 14:42 EXAMPLE.TXT;1 (615,2) 0./0. 21-APR-23 14:42 [1,4] [RWED,RWED,RWED,RE] TOTAL OF 0./0. BLOCKS IN 1. FILE
- dhosek 3y ago
  I rather liked VMS conventions as it was immediately obvious what was the directory part of the path and what was the filename and the device. You could create virtual devices as well, so for example, with VMS TeX, I had TEX_ROOT defined to point to the root of the TeX distribution and you would have TEX_ROOT:[INPUTS] for the input directory, TEX_ROOT:[MF] for Metafont files, TEX_ROOT:[EXE] for executables, etc. and everything was logically arranged. CLD files were another wonderful thing where you could define your CLI interface in an external file and let the OS handle argument and option parsing for you.

tinus_hn 3y ago

It’s the flip side of the ‘we bent over backwards so SimCity runs’ coin. Even though Windows hasn’t supported programs out of this era since 64bit became the standard, it’s still held back by clinging on to the legacy. Because it doesn’t dare say ‘this is too old, run it in a VM’.