Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
this.title = "gg Microsoft"
this.metadata = {
rant: true,
long: true,
super_long: true,
has_summary: true
}
// Also:
let microsoft = "dead" // please?
tl;dr: Windows' MAX_PATH is the devil, and it basically does not allow you to copy files with paths that exceed this length. No matter what. Even with official fixes and workarounds.
Long story:
So, I haven't had actual gainful employ in quite awhile. I've been earning just enough to get behind on bills and go without all but basic groceries. Because of this, our electronics have been ... in need of upgrading for quite awhile. In particular, we've needed new drives. (We've been down a server for two years now because its drive died!)
Anyway, I originally bought my external drive just for backup, but due to the above, I eventually began using it for everyday things. including Steam. over USB. Terrible, right? So, I decided to mount it as an internal drive to lower the read/write times. Finding SATA cables was difficult, the motherboard's SATA plugs are in a terrible spot, and my tiny case (and 2yo) made everything soo much worse. It was a miserable experience, but I finally got it installed.
However! It turns out the Seagate external drives use some custom drive header, or custom driver to access the drive, so Windows couldn't read the bare drive. ffs. So, I took it out again (joy) and put it back in the enclosure, and began copying the files off.
The drive I'm copying it to is smaller, so I enabled compression to allow storing a bit more of the data, and excluded a couple of directories so I could copy those elsewhere. I (barely) managed to fit everything with some pretty tight shuffling.
but. that external drive is connected via USB, remember? and for some reason, even over USB3, I was only getting ~20mb/s transfer rate, so the process took 20some hours! In the interim, I worked on some projects, watched netflix, etc., then locked my computer, and went to bed. (I also made sure to turn my monitors and keyboard light off so it wouldn't be enticing to my 2yo.) Cue dramatic music ~
Come morning, I go to check on the progress... and find that the computer is off! What the hell! I turn it on and check the logs... and found that it lost power around 9:16am. aslkjdfhaslkjashdasfjhasd. My 2yo had apparently been playing with the power strip and its enticing glowing red on/off switch. So. It didn't finish copying.
aslkjdfhaslkjashdasfjhasd x2
Anyway, finding the missing files was easy, but what about any that didn't finish? Filesizes don't match, so writing a script to check doesn't work. and using a visual utility like windirstat won't work either because of the excluded folders. Friggin' hell.
Also -- and rather the point of this rant:
It turns out that some of the files (70 in total, as I eventually found out) have paths exceeding Windows' MAX_PATH length (260 chars). So I couldn't copy those.
After some research, I learned that there's a Microsoft hotfix that patches this specific issue! for my specific version! woo! It's like. totally perfect. So, I installed that, restarted as per its wishes... tried again (via both drag and `copy`)... and Lo! It did not work.
After installing the hotfix. to fix this specific issue. on my specific os. the issue remained. gg Microsoft?
Further research.
I then learned (well, learned more about) the unicode path prefix `\\?\`, which bypasses Windows kernel's path parsing, and passes the path directly to ntfslib, thereby indirectly allowing ~32k path lengths. I tried this with the native `copy` command; no luck. I tried this with `robocopy` and cygwin's `cp`; they likewise failed. I tried it with cygwin's `rsync`, but it sees `\\?\` as denoting a remote path, and therefore fails.
However, `dir \\?\C:\` works just fine?
So, apparently, Microsoft's own workaround for long pathnames doesn't work with its own utilities. unless the paths are shorter than MAX_PATH? gg Microsoft.
At this point, I was sorely tempted to write my own copy utility that calls the internal Windows APIs that support unicode paths. but as I lack a C compiler, and haven't coded in C in like 15 years, I figured I'd try a few last desperate ideas first.
For the hell of it, I tried making an archive of the offending files with winRAR. Unsurprisingly, it failed to access the files.
... and for completeness's sake -- mostly to say I tried it -- I did the same with 7zip. I took one of the offending files and made a 7z archive of it in the destination folder -- and, much to my surprise, it worked perfectly! I could even extract the file! Hell, I could even work with paths >340 characters!
So... I'm going through all of the 70 missing files and copying them. with 7zip. because it's the only bloody thing that works. ffs
Third-party utilities work better than Microsoft's official fixes. gg.
...
On a related note, I totally feel like that person from http://xkcd.com/763 right now ;;21 -
It's kind of neat knowing people who are famous for things I don't care about, and having their numbers / talking semi-regularly. They're a special person to so many others, but to me they're just some random person that's mildly annoying.
Like API Guy.
Freaking API Guy.
He's a millionaire musician who's adored by literally millions of people, but none of them know he writes absolutely terrible APIs, zero tests, rushes to the shiniest new things, and happily agrees to everything (often without listening) only to deny it later. Absolutely infuriating.
Or knowing one of Netscape founders as that strange and really terrible trumpet player with the great tequila. He did give me his copy of The C Programming Language (the bible) though. He was cool. Super weird, but cool.
It's just a strange feeling. I don't care, and yet others inexplicably think I should. I don't understand it. They're just people? idk.14 -
So I wrote an application that loads data from a 3rd party API. It allows the user to enter a record locator number and pull it up. By design, the value can be a partial match and it will pull up the record still.
The first API call I make only took 2-3 seconds, so I didn't see an issue as it's loading most of the data the app needs. I keep the filters/fields as they are and move on.
Fast forward 6 months. The user is complaining that the records are taking 30-45 seconds to load. Sure enough, load times are terrible. I've made lots of changes to what fields I'm loading through the API, and I'm calling several additional APIs, so I start pulling pieces of code out to see if anything improves. They all barely make any difference--still 30+ second load times. I end up removing everything except the first API call I developed that was taking 2-3 seconds before. Still taking 30+ seconds.
The 3rd party API allows you to filter using "starts with" or "contains". I used "contains" initially and had no issue, but I decided to try "starts with" since it should fit most use cases.
Load time is less than one second. I add back everything else. Load time is just over a second.
It seems that the 3rd party updated the API and multiplied load times by 10 when using that particular filter. I spent almost an hour on this since the platform doesn't support performance or debugging tools very well, and it all came down to a one line fix.4 -
Unintuitive APIs, with poor documentation and terrible parameter names. It's like they don't want me to use it3
Top Tags
Weekly Rant
View