Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

Parent Full thread

That reminds me of an incident when I was in year 8: seeing how deeply nested I could get directories on Windows. H:\a\a\a\a\..., eventually it stopped working. (I played the game with my friend... he went for creating a new directory at each level, after a little I became sensible and went for copying and pasting, thus multiplying the depth by two each level which of course achieves the goal pretty quickly - so I won by a considerable margin.)

The school IT manager (who, incidentally, apart from this once I was always on good terms with) was rather annoyed at me the next day, for the nightly backup had fallen over the previous night and he had found the problem. You see, what to me was H:\ was \\galaxy\users$\chrism, which on that server was D:\users\chrism. So that 256-or-so character path became longer than 256 characters on the server and the backup software hadn't been written carefully enough to cope with what was a perfectly valid NTFS path, but not a valid path for the normal Win32 API function calls.

How was I to know it would do that?

Years ago, I was an applications programmer in San Francisco working on a timesharing language called EPS. The mainframes were all in Massachusetts. (Think dial-up terminals, mainframes, and 450 BAUD being considered fast.)

EPS, an interpreted language, was designed to let financial analysts run economic projections. It contained various kinds of arrays.

One day, the systems programmers announced a new feature, first released to the test mainframe: a new structure, called containers IIRC, with the twist being that any cell in a container could itself consist of a container.

You know where this is going:

    For I = 1 to 100
      ContX[1] = ContX
    EndFOR

10 seconds later, EPS on the test mainframe had crashed. Coincidence? Hmmmmmm.

So far, my cover was my inquiring mind. But then I ran the loop again, with the same results.

A minute later, there was Massachusetts on the phone, in the person of my friend Kevin, lead EPS developer: "Hey, the answer is 47. What the hell are you doing?"

Difference between hackers and coders -

Rule: "You can have at most 50 sub-directories."

coder-action:

     #define MAX_SUB_DIRECTORY_NUM 50

hacker-action:

    main(int argc, char *argv[]) {
      int i;
      for (i = 0; i < atoi(argv[1]); i++) {
          create_subdir( ... ); 
      }
    }

Plus experiments.

The difference is that the coder is just doing their job so they note the limitation and move on, the hacker is curious and trys to test to see if its a hard limit, a soft limit, a big problem, a little problem.

A good developer should be testing for that stuff too. But hackers test these things out of curiosity, developers do it out of attention to detail. A great developer will do both :)

My brother did this exact same thing (competing with his friend to try to make as many folders as possible), only he got a 1 week suspension for "hacking". The IT manager was really pissed and pressed the school administrators to make an example out of them.

I was outraged. Basically, the IT manager preferred to use punishment as his means of security, rather than actually doing his job.

Being able to break something =/= IT not doing their job.

Tossing a brick through a window doesn't mean that the window should have been thicker.

Except that this was not 'tossing a brick,' it was maybe knocking on a window to see what sound it makes, and the window then falling apart for no apparent reason.

There is nobody to blame for this, actually. Neither could the kid have known that this was bad (and the child-like curiosity is hardly something worth a punishment,) nor could the sysadmin really do anything to prevent it, except hang up a memo: please don't do that.

Though, in that case, you'd have some kids doing that over and over again out of a very different kind of curiosity.

I agree that we should not punish kids for expermentation (I am outraged when schools do anything other than encourage it). However, if playing around with a computer causes notable damage, I do have to wonder what would happen with viruses or someone who is actually malicius.

The NTFS 256-character-path bit me before when I moved a deeply-nested folder from somewhere with a short path (like the root of a disk) to somewhere with a slightly longer one (like my desktop) and then went to delete it. Windows doesn't even complain in this case--it just completely ignores all attempt to delete the folder (even if you, say, put it in the trash and then empty the trash) because it can't complete the process of gathering up the list of paths to delete.

It's very confusing when you're not expecting it--you can dig into the folder and delete all the subdirectories of it that don't have overlong paths just fine, but there'll be one series of empty directories left over that just refuse to go away. Then you flatten them out from their nested configuration, and suddenly the problem goes away.

Had this problem once as well. It's so weird that explorer doesn't use the API without the path length restriction...

One of many examples of why Windows's arbitrary path length restriction is ridiculous.

Most UNIX systems have a PATH_MAX. It's not just Windows.

PATH_MAX is defined but meaningless on both Linux and OS X.

Unfortunately, this is not true. The OS X kernel can't deal with paths longer than MAXPATHLEN, which is defined as 1024.

Perhaps, but Windows's is a bit too low.

While MAX_PATH is 260, most of the Unicode variants of the API functions allow for paths of 32,767 characters [1]. That seems like a decent length.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...

So there's a constant for path length that only applies sometimes...

This is also the case on Unix. According to Advanced Programming in the Unix Environment, it is true of many of these so-called limits. The POSIX standard defined many values that were too small for modern-day use, such as _POSIX_PATH_MAX set to 255. The non-posix values are not all defined in limits.h, and must be queried at runtime. Even then, some are indeterminate. But at least you're not relegated to 255 characters;)

Oh, that's somewhat reassuring. I'll surely benefit from it in 10 years time. :/

I'm not sure that I know what you mean. These functions aren't obscure and have been around for quite a while. For example: CreateFileW [1]. It's just good hygiene to use the Unicode variants and normalize to UNC where appropriate. This has been the case for years.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...

I mean that to maintain compatibility with legacy stuff I expect I won't be able to take advantage of it for quite a while.

The write limit should be lower than the read limit.

I had a worse problem when I helped my parents recover their backups. The backup itself had a fair amount of folder nesting, but was within the 256 character limit. At some point, they moved the backup into another folder that had the date, and computer for the backups. When they tried to access it, Windows gave a cryptic error message about corrupted files.

That reminds me of using the undelete utility that came around the Windows 3.1/DOS 6.2 sort of time. All the files it would offer to recover had file names like "testdoc.do?", and if you didn't set the final character it created a file with a wildcard in the name.

Do that, but then rename each folder to a very long name, and go back one directory up in the tree e.g. d:\h\h\h becomes d:\h\h\very_long_h then d:\h\verl_long_h\very_long_h, etc.

It was "simple" way to hide files, by making their names very long indeed.

Reply on news.ycombinator.com