Hacker News Reader

Comment by eponeponepon | Hacker News Reader

I think I've told this story before, but several years ago I discovered this stuff for myself.

I had tidied up a script distribution that had been unloved for a while and got a bit out of hand. I'd been working at home on a Debian laptop, and committed my changes back to Subversion - one of which was to gather up and organise some auxiliary files into one neat and tidy directory. Naturally, since the script already had ./bin, ./lib and ./etc, I went with aux.

I came into work after the weekend to find my Windows-based colleagues, who were in the habit of checking out a single working copy of the entire repo, in full panic mode because "Subversion is broken, IT say we might have lost everything"...

These days I name aux directories 'etc'.

View on HN

This gives a whole new meaning to source code not being portable.

I have lost count of the number of times I have checked out a large Java application which hits the 256 character MAX_PATH limit on Windows. Is a huge pain in the ass as checkout from git or whatever usually works fine but when you try and access the 40 deep folder tree Explorer will error on you.

While I have as much disrespect for Windows and MS in general as any web developer who had to deal with IE, I think this issue is a bug in Git.

Windows git executable should be aware of OS limitations and should be able to work around them. Of course, Windows API should also fail to create invalid fs objects, so there's that...

I kind of agree and disagree at the same time.

Microsoft provide file system access which is not impacted by MAX_PATH and that is what git is using when it writes to the file system. If anything I think Microsoft should fix Explorer which they kind of have in Windows 10 with the long path option.

I don't know enough about why Microsoft still have the MAX_PATH problem. I am guessing, like most things Microsoft, it is due to legacy compatibility.

An easy way around this is the `subst` command, which lets you map a folder to a drive letter; if it happens frequently, write up a batch/vbs script and put it in the right-click memu. Of course, if you extracted a prank zip file, you may want to find another method, as there's liable to be far longer paths nested in there...

Oh yeah there are plenty of workarounds, just an annoyance when it catches you out. Not much of an issue if you are on Windows 10 as you can enable Microsoft's long path setting. I don't often use Windows these days though so it is even less of an issue :)

Another way for source code to be not portable is to include two files with different casing in the same directory, for example "bin" and "BIN".

You can't work properly with that on the case-insensitive file systems on Windows and Mac.

You can actually turn on case insensitivity in windows, though not all software will like it.

NT has always supported case-insensitivity (at least somewhat) via a registry key[1].

With windows 10's linux subsystem, there is now a new command to make a _directory_ case sensitive[2].

[1]: http://www.nicklowe.org/2012/02/understanding-case-sensitivi... [2]: https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-...

Windows is already case insensitive, no? Case insensitive but case preserving (a file named in ALL CAPS will remain ALL CAPS and can be accessed with lowercase letters as well.)

Hahaha! I think I'm going to include an aux or con file in every project I make from now on :)

For best effect, include both 'aux.\/aux.c' and 'aux.\/AUX.c', to also lance several other pustules of brain damage.

Reply on news.ycombinator.com