• Matthew Hall (unregistered) in reply to Anon
Anon:
Recursion

re.curs.ion

Definition:

See recursion

Or perhaps even better:

Recursion (n) re.curs.ion Definition: See recursion (n-1)

-matt (P.S: Recursion (0) re.curs.ion Definition: termination)

• (cs) in reply to Quirkafleeg
Quirkafleeg:
`rm -rf /`

That won work in ASP. Try: del c:\

• SR (unregistered) in reply to djmaze
djmaze:
Quirkafleeg:
`rm -rf /`

That won work in ASP. Try: del c:</div>

We can only dream... ;o)

• (cs) in reply to zedhex
zedhex:
ClaudeSuck.de:
Not everybody knows recursion

They do in places where your Aunt is your sister. But maybe small town hicks have trouble applying it to abstract concepts.

The best math teacher I had was Aunt Mom.

• Peter. (unregistered) in reply to tovarich
tovarich:
Smart early men counted "one, two, many... many-one, many-two, many-many..." etc.

Early people COUNTED from zero to twenty (hands plus feet) and then switched over to calculations, twenty-one, twenty-two, one-hundred-and-... etc.

Computers only count from 0 to 1 and then do calculations for everything else, two-times-one and four-times-one, etc. Therefore Zero,One,Many is indeed the best choice as it is the most natural way for computers to deal with any number.

http://en.wikipedia.org/wiki/Pirah%C3%A3_people

The Piraha, perchance?

• Franz Kafka (unregistered) in reply to Resuna
Resuna:
ClaudeSuck.de:
Not everybody knows recursion
1. If you don't know recursion you shouldn't be working as a software developer.
1. This doesn't actually need recursion, you can maintain a directory stack manually.

What's the difference? All you've done is recurse explicitly rather than implicitly.

• Yuliy (unregistered) in reply to greg barton
greg barton:
removeFiles(dirName) { dir.delete files for each subDir { removeFiles(subDir) } }

Because an anti-social person will nest directory structures until your program stack overflows and runs arbitrary code.

Actually my code contains a bug as well it should have been something like:

EmptyFolder = fileSystem.currentBottomDirOnly();

You don't want to store the entire directory path in RAM.

Why not? The max path length on a windows system is 32K, and is smaller on Linux. You're not going to overflow the stack with that as your input. Especially since the string contents don't actually go onto the stack.

• (cs) in reply to Mike
Mike:
RogerWilco:
I know that when I studied ancient greek, I found out that they basically could count to 10000. Their word for 10000 and anything beyond that was μυρια (Myriad). If it was far beyond 10000 they might use μυρια μυρια. Only Archimedes is known to have had an interest in numbers larger than μυρια and tried to invent a way to count them.

I've always wondered how it would be to live in a world where large numbers just aren't needed.

While the virtual need for huge numbers is obvious, there really isn't an actual need for large numbers even in today's society. Most people don't comprehend a trillion, or even a million. If you ask them what a million is, most (Americans at least) will think of a million dollars, even though most don't know what a million dollars looks like or even what they would do with it.

But what if it were a million marbles? What is the mass and volume of a million tightly packed marbles? Would it fit in my upstairs bathroom? What's the monetary value, i.e. would it be worth acquiring and reselling a million marbles? I would estimate 99%+ couldn't grasp a single one of these concepts.

A few things to ponder:

1. I am 35 years old with children. I make \$90K a year. How much money do I insure myself for in case the unthinkable happens and I need to replace what I would have earned?

2. My cell phone uses a frequency of ~2.4 billion cycles per second. How does the manufacturer verify the correct frequency? How did the engineers design it?

3. How many miles (kilometers for you international types) do I drive in a 10 year period? In a lifetime?

Only liberal arts majors would think that 1 million is a large number. If you find visualizing large numbers hard, I would suggest learning about logarithms.

• Segfault (unregistered)

Now where do I go to find this job? I'd love to find a development job that doesn't involve me living in or near a city. Heck, I think it's even safe to say I could be your new best coder :-)

• usitas (unregistered) in reply to Mike
Mike:
RogerWilco:
I know that when I studied ancient greek, I found out that they basically could count to 10000. Their word for 10000 and anything beyond that was μυρια (Myriad). If it was far beyond 10000 they might use μυρια μυρια. Only Archimedes is known to have had an interest in numbers larger than μυρια and tried to invent a way to count them.

I've always wondered how it would be to live in a world where large numbers just aren't needed.

While the virtual need for huge numbers is obvious, there really isn't an actual need for large numbers even in today's society. Most people don't comprehend a trillion, or even a million. If you ask them what a million is, most (Americans at least) will think of a million dollars, even though most don't know what a million dollars looks like or even what they would do with it.

But what if it were a million marbles? What is the mass and volume of a million tightly packed marbles? Would it fit in my upstairs bathroom? What's the monetary value, i.e. would it be worth acquiring and reselling a million marbles? I would estimate 99%+ couldn't grasp a single one of these concepts.

This bottled my mind

• greg barton (unregistered) in reply to Yuliy
Yuliy:
Why not? The max path length on a windows system is 32K, and is smaller on Linux. You're not going to overflow the stack with that as your input. Especially since the string contents don't actually go onto the stack.

And if Microsoft markets Windows 2010 with a "no limits file system" you are screwed. The title of this WTF is "Should be enough" that is a WTF, please consider.

• evilspoons (unregistered) in reply to Raedwald
Raedwald:
I can't believe that nobody has pointed out that 640 levels of directory should be enough for anybody.

I know what you're trying to allude to, but just as an annoying tidbit of information, I believe the maximum path length on Windows is 260 characters... so with one character directory names and the backslash character, you're gonna be stuck well before 130 levels.

• (cs) in reply to Consultuning
Consultuning:
...YAGNI (you're not going to need it) ...

+1, Subtle

• Mike (unregistered) in reply to frits
frits:
Mike:
RogerWilco:
I know that when I studied ancient greek, I found out that they basically could count to 10000. Their word for 10000 and anything beyond that was μυρια (Myriad). If it was far beyond 10000 they might use μυρια μυρια. Only Archimedes is known to have had an interest in numbers larger than μυρια and tried to invent a way to count them.

I've always wondered how it would be to live in a world where large numbers just aren't needed.

While the virtual need for huge numbers is obvious, there really isn't an actual need for large numbers even in today's society. Most people don't comprehend a trillion, or even a million. If you ask them what a million is, most (Americans at least) will think of a million dollars, even though most don't know what a million dollars looks like or even what they would do with it.

But what if it were a million marbles? What is the mass and volume of a million tightly packed marbles? Would it fit in my upstairs bathroom? What's the monetary value, i.e. would it be worth acquiring and reselling a million marbles? I would estimate 99%+ couldn't grasp a single one of these concepts.

A few things to ponder:

1. I am 35 years old with children. I make \$90K a year. How much money do I insure myself for in case the unthinkable happens and I need to replace what I would have earned?

2. My cell phone uses a frequency of ~2.4 billion cycles per second. How does the manufacturer verify the correct frequency? How did the engineers design it?

3. How many miles (kilometers for you international types) do I drive in a 10 year period? In a lifetime?

Only liberal arts majors would think that 1 million is a large number. If you find visualizing large numbers hard, I would suggest learning about logarithms.

1. This depends on a lot of information that I don't have, but a reasonable estimation is \$900,000.

2. Neither owning, using, manufacturing, nor testing that phone required possessing one million of anything.

3. The average driver drives ~1,000 miles a month, 12,000 per year, and with 50 years of driving would reach ~600,000 total miles driven. An OTR truck driver would clear nearly 200,000 miles per year legally.

While you make a persuasive argument, this still doesn't translate to the average person understanding what a million is. I can use math to figure out that my upstairs bathroom has a volume of ~360 cubic feet, minus toilet, vanity, bathtub, and through the theory of sphere packing I can determine that one million marbles will occupy about 77 cubic feet, making them fit comfortably inside the bathroom. Until I actually do that, though, I still don't know what a million marbles looks like, and I would bet that no more than 100 people in the world have ever seen it.

• greg barton (unregistered) in reply to evilspoons
evilspoons:
I know what you're trying to allude to, but just as an annoying tidbit of information, I believe the maximum path length on Windows is 260 characters... so with one character directory names and the backslash character, you're gonna be stuck well before 130 levels.

This is shattering my image of The Daily WTF being professionals mocking the incompetent. If you write broken code and analyze the OS to see if you can get away with it you are annoying.

• fjf (unregistered) in reply to greg barton
greg barton:
You don't want to store the entire directory path in RAM.
Where do you think the OS stores the path?

As for your hypothetical no-limits-file system, if it really included paths larger than RAM size: All system functions that return paths or take them as parameters would fail, so you'd need a major interface changes. So while I'm all for avoiding arbitrary limits, planning in advance for something hypothetical like this would be going too far ...

• fjf (unregistered) in reply to t3knomanser
t3knomanser:
Well, he was maintaining his stack in static code instead of a data structure. That's a problem if the depth of the environment ever changes.
This can easily be solved by employing self-modifying code ...
• Lucas (unregistered)

A programmer either understands recursion or not. This applies to every other programmer, too.

• Zapp Brannigan (unregistered) in reply to Steve the Cynic
Steve the Cynic:
So Easy A Caveman Could Do It:
The usual joke is that early man counted "one, two, many". After much education, many of us could count indefinitely and not tire. It's interesting to imagine whether that actually works against us: there's something for developers who know that, after two or more levels, you may as well generalize to "many".
I guess that makes our interesting number sequence: zero, one, many.
I think it should be zero, FILE_NOT_FOUND, many.
• interested (unregistered) in reply to TopCod3r
I have always thought of recursion as being one of those "ivory tower" things that live in the realms of theory and academia and was never meant to be used in a production system like this.

I'd be interested in learning a sorting algorithm as good as QuickSort that does not use recursion.

• Mike (unregistered) in reply to fjf
fjf:
greg barton:
You don't want to store the entire directory path in RAM.
Where do you think the OS stores the path?

\$MFT?

http://www.pcguide.com/ref/hdd/file/ntfs/archMFT-c.html

• Paul (unregistered) in reply to fjf
fjf:
greg barton:
You don't want to store the entire directory path in RAM.
Where do you think the OS stores the path?

As for your hypothetical no-limits-file system, if it really included paths larger than RAM size: All system functions that return paths or take them as parameters would fail, so you'd need a major interface changes. So while I'm all for avoiding arbitrary limits, planning in advance for something hypothetical like this would be going too far ...

Obviously, you'd store the directory path in a file on the disk, and pass the path to that file around.

Oh, wait...

• caper (unregistered)

This code does not perform a directory tree deletion. It only deletes plain files from within the tree.

• egc52556 (unregistered) in reply to ClaudeSuck.de
ClaudeSuck.de:
Not everybody knows recursion
If you knew recursion, like I knew recursion, then, like, new recursion I gnu re-curse in. Repeat as necessary.
• (cs) in reply to Mike
Mike:
frits:
Mike:
RogerWilco:
I know that when I studied ancient greek, I found out that they basically could count to 10000. Their word for 10000 and anything beyond that was μυρια (Myriad). If it was far beyond 10000 they might use μυρια μυρια. Only Archimedes is known to have had an interest in numbers larger than μυρια and tried to invent a way to count them.

I've always wondered how it would be to live in a world where large numbers just aren't needed.

While the virtual need for huge numbers is obvious, there really isn't an actual need for large numbers even in today's society. Most people don't comprehend a trillion, or even a million. If you ask them what a million is, most (Americans at least) will think of a million dollars, even though most don't know what a million dollars looks like or even what they would do with it.

But what if it were a million marbles? What is the mass and volume of a million tightly packed marbles? Would it fit in my upstairs bathroom? What's the monetary value, i.e. would it be worth acquiring and reselling a million marbles? I would estimate 99%+ couldn't grasp a single one of these concepts.

A few things to ponder:

1. I am 35 years old with children. I make \$90K a year. How much money do I insure myself for in case the unthinkable happens and I need to replace what I would have earned?

2. My cell phone uses a frequency of ~2.4 billion cycles per second. How does the manufacturer verify the correct frequency? How did the engineers design it?

3. How many miles (kilometers for you international types) do I drive in a 10 year period? In a lifetime?

Only liberal arts majors would think that 1 million is a large number. If you find visualizing large numbers hard, I would suggest learning about logarithms.

1. This depends on a lot of information that I don't have, but a reasonable estimation is \$900,000.

2. Neither owning, using, manufacturing, nor testing that phone required possessing one million of anything.

3. The average driver drives ~1,000 miles a month, 12,000 per year, and with 50 years of driving would reach ~600,000 total miles driven. An OTR truck driver would clear nearly 200,000 miles per year legally.

While you make a persuasive argument, this still doesn't translate to the average person understanding what a million is. I can use math to figure out that my upstairs bathroom has a volume of ~360 cubic feet, minus toilet, vanity, bathtub, and through the theory of sphere packing I can determine that one million marbles will occupy about 77 cubic feet, making them fit comfortably inside the bathroom. Until I actually do that, though, I still don't know what a million marbles looks like, and I would bet that no more than 100 people in the world have ever seen it.

I can see what you're getting at, but I'm not sure I agree exactly. We still don't really use large numbers: we almost always use units that are themselves divisible into smaller units. Whether you're talking of 1 million pounds - which to most people is one of a unit called 'a million pounds' - or ten kilometres - which is really ten lots of a thousand metres, each thousand being lumped together into a 'kilometre'.

When we do use specific large numbers, we have to count them indirectly - simply because it's impractical to count that high. Generally, though, things that are sold in numbers too high to practically count are worth little enough relative to the transaction that we can estimate the number some other way - by weighing, for example.

For what it's worth, I have seen a million of something (enumerated), although I didn't count them. Anyone who's seen a palletload of anything small will have done - screws, sweets, sheets of paper, for example.

• Markku Uttula (unregistered) in reply to interested
interested:
I'd be interested in learning a sorting algorithm as good as QuickSort that does not use recursion.

Take a look at InsertionSort... oh, you meant to say "as fast as" instead of "as good as" :)

• fjf (unregistered) in reply to Mike
Mike:
fjf:
greg barton:
You don't want to store the entire directory path in RAM.
Where do you think the OS stores the path?

\$MFT?

http://www.pcguide.com/ref/hdd/file/ntfs/archMFT-c.html

I don't think the current working directory (e.g.) is stored there ...

• fjf (unregistered) in reply to Markku Uttula
Markku Uttula:
interested:
I'd be interested in learning a sorting algorithm as good as QuickSort that does not use recursion.

Take a look at InsertionSort... oh, you meant to say "as fast as" instead of "as good as" :)

Even that is not precise enough. QuickSort's worst-case performance is O(n^2) which almost all sorting algorithms except BogoSort achieve. Many are better in this way with O(n log n) worst case. But average performance WRT suitable measures is often best in QS.

• greg barton (unregistered) in reply to Paul
fjf:
Where do you think the OS stores the path?

As for your hypothetical no-limits-file system, if it really included paths larger than RAM size: All system functions that return paths or take them as parameters would fail, so you'd need a major interface changes. So while I'm all for avoiding arbitrary limits, planning in advance for something hypothetical like this would be going too far ...

You mean to say that all programs that concatenate paths as strings and pass them as a parameter would fail. Which is exactly what I'm saying is wrong. BTW every folder in a directory has an node ID (i-node in Linux), so if say this node ID was a 32bit integer, and the file system had a folder called "wtf_elite_codez" that was nested under 1 billion parent folders. It would take 4 bytes to handle that folder non-recursively. With something like

chdir(folderNodeID). idParent = folderParentNdodeID(folderNodeID) etc.

My hypothetical no limit file system is not far fetched (change node IDs to 128 bit if you want), only with your implementation would it be impractical.

Remember the title of this is "Should be enough". I think I'm winning this debate.

• (cs) in reply to So Easy A Caveman Could Do It
So Easy A Caveman Could Do It:
Recursion jokes are funny. ENDLESS recursion jokes are not funny.

Moral: Don't forget the base case or you'll never get to hear the punchline.

```if (i > 0)
return tellJoke(--i);
else
return "Orange you glad I didn't say 'banana'?"
```
• Bim Job (unregistered) in reply to ClaudeSuck.de
ClaudeSuck.de:
Resuna:
ClaudeSuck.de:
Not everybody knows recursion
1. If you don't know recursion you shouldn't be working as a software developer.

2. This doesn't actually need recursion, you can maintain a directory stack manually.

Not very elegant

On the contrary, it's equivalently elegant.

All you'd be doing is to memoize full path names on the way until you get to a point where there are no more directories (ignoring Unix conventions for the sake of simplicity). Delete all the files, pop the stack, and continue.

As always, iteration and recursion are equivalent (as you well know). The benefit in this case is that, given a procedural language, it's easier to explain the iterative approach -- and, I would argue, more likely to produce a bug-free result. (Some of the suggestions above are not bug free.) Given a functional language: yes, I'd agree with you.

Mind you, my first thought was definitely "surely there's a library function to do this?"

• Kingsnake (unregistered)

This would not be a multi-billion dollar furniture company headquartered in western Wisconsin, by any chance, would it? Because it sure sounds like the place I used to work ...

• fjf (unregistered) in reply to greg barton
greg barton:
fjf:
[...], so you'd need major interface changes.
[...]With something like chdir(folderNodeID). etc.

[...] I think I'm winning this debate.

By confirming my points? Well, if you think so ...
• Kingsnake (unregistered) in reply to Kingsnake

... Because, if it is, I was the other guy crazy enough to move there in the last 10 years from a large city (Milwaukee).

And the people who did not work at Company A, worked at the chicken rendering plant up the street.

• Quirkafleeg (unregistered) in reply to frits
Mike:
What is the mass and volume of a million tightly packed marbles? Would it fit in my upstairs bathroom? What's the monetary value, i.e. would it be worth acquiring and reselling a million marbles? I would estimate 99%+ couldn't grasp a single one of these concepts.
Mass: 10⁶× the mass of one marble.

Volume:if each one is around 1cm³, then a bit over 1m³ (but there'd be empty space, which would increase it a bit; I've not properly taken that into account).

As for buying and re-selling, well, what quantities would you be selling them in? 10? 25? 100? That's at least 10,000 units, and you'd want reasonable markup (and I'd expect a pack of 100 to cost a bit less than 10 packs of 10).

frits:
A few things to ponder:

1. I am 35 years old with children. I make \$90K a year. How much money do I insure myself for in case the unthinkable happens and I need to replace what I would have earned?
Call that \$50k after the tax man gets his share. Let's also say that prices are doubled over the next 30 years (naïve calculation; \$75k/year). That's \$2¼M, a.k.a. windfall there for the spending.
[…]
• How many miles (kilometers for you international types) do I drive in a 10 year period? In a lifetime?
• Typically? I wouldn't like to say, but there's no reason that I can see why a long-distance driver couldn't do a million miles in 10 years.
Only liberal arts majors would think that 1 million is a large number. If you find visualizing large numbers hard, I would suggest learning about logarithms.
If a logarithm falls in a forest…
• fjf (unregistered) in reply to greg barton
greg barton:
You mean to say that all programs that concatenate paths as strings and pass them as a parameter would fail. Which is exactly what I'm saying is wrong. BTW every folder in a directory has an node ID (i-node in Linux), so if say this node ID was a 32bit integer, and the file system had a folder called "wtf_elite_codez" that was nested under 1 billion parent folders. It would take 4 bytes to handle that folder non-recursively.
So what if you want to tell the user where the file is (give them the ID, much nicer to remember than a path?), or ask a user for a file (sure, file selection dialog with 1 billion levels, and make sure to store its temporary data on disk because it may exceed RAM size), store the file name in an archive file (copy it piece by piece), etc.? Yes, it can all be done, but it would look entirely different from what we currently do. That was my point -- why plan for an unlikely case when the environment you'd need would be so different that your program wouldn't run in it anyway. More specifically: Why worry about recursion depth when you'd have to completely rewrite anything filename related anyway?
greg barton:
My hypothetical no limit file system is not far fetched (change node IDs to 128 bit if you want),
There are in fact ways to store numbers of unlimited size, given unlimited memory, but your approach of "increase size to \$SHOULD_BE_ENOUGH bits" is not one. So by your own measure you fail (though, of course, practically, 2^128 should be enough for almost everyone ;-).
• fjf (unregistered) in reply to greg barton
greg barton:
You mean to say that all programs that concatenate paths as strings and pass them as a parameter would fail. Which is exactly what I'm saying is wrong. BTW every folder in a directory has an node ID (i-node in Linux), so if say this node ID was a 32bit integer, and the file system had a folder called "wtf_elite_codez" that was nested under 1 billion parent folders. It would take 4 bytes to handle that folder non-recursively.
So what if you want to tell the user where the file is (give them the ID, much nicer to remember than a path?), or ask a user for a file (sure, file selection dialog with 1 billion levels, and make sure to store its temporary data on disk because it may exceed RAM size), store the file name in an archive file (copy it piece by piece), etc.? Yes, it can all be done, but it would look entirely different from what we currently do. That was my point -- why plan for an unlikely case when the environment you'd need would be so different that your program wouldn't run in it anyway. More specifically: Why worry about recursion depth when you'd have to completely rewrite anything filename related anyway?
greg barton:
My hypothetical no limit file system is not far fetched (change node IDs to 128 bit if you want),
There are in fact ways to store numbers of unlimited size, given unlimited memory, but your approach of "increase size to \$SHOULD_BE_ENOUGH bits" is not one. So by your own measure you fail (though, of course, practically, 2^128 should be enough for almost everyone ;-).
• sino (unregistered) in reply to Consultuning
Consultuning:
Actually, this is the kind of situation that worries me when the latest generation of programmers get to work under the new "agile" methodologies. YAGNI (you're not going to need it) advocates them just to solve the problem at hand and don't bother with abstractions or generalizations.

In this case, the programmer could have been working with a specification that called for no more than, say, three nested folders. Who can blame him/her for not implementing a more general solution? He runs into the risk of someone pointing at the beatiful, generic solution and yell "YAGNI"

On the other hand, a solution that specifices that this has to work for an undefined number of nested folders is not going to be understood by business folks anyway. Recursion is hard enough to understand for the average programmer, let's not even talk about explaining it outside the programming world.

I'm not saying that "agile" is bad whatsoever, just that it does have its own drawbacks, and this is one of them. Too much focus on pragmatism can potentially lead to these kind of ridiculous situations.

Oh, and by the way, any type of recursion can be implemented iteratively by crafting a stack data structure. It is just much more messy and un-functional programming to do so. Sometimes is more efficient, and sometimes there is no performance gain to justify the loss of readability. See, this is what worries me about the newer generations, they don't have good enough grasp of the fundamentals.

Or were you just using that as a launching pad for demonstrating your big smarts about unwinding recursion with a stack, like all the other stack > recursion commenters? Sorry, of course I meant by crafting a stack.

0_o

See, this is what worries me about developers arrogant enough to make unfounded claims about such things as "the newer generations", without considering the shoulders they themselves stood on.

Or do you still code with a magnetized needle and a steady hand?

Jan:
Welcome back TopCod3r. Good luck.

XD

• (cs)

I am sorry :)

• greg barton (unregistered) in reply to fjf
fjf:
By confirming my points? Well, if you think so ...

Ok google "INode file system structure" "or INode pointers". I'm not confirming your point as there is no major interface changes. The operating system stores INode numbers and INode pointers for traversing directory structures. This is how unix, linux, ntfs layout directory structures. It's how all your command line programs traverse directories, it's how the kernel traverses directories. So where is the major interface change? And you tried to pose a rhetorical question but instead asked a question with a definite answer. The operating system stores the current path as a single number. Don't try and get into technical arguments if you don't know what your talking about it makes you look silly.

• Eddie (unregistered) in reply to recursive ClaudeSuck
recursive ClaudeSuck:
ClaudeSuck.de:
Not everybody knows recursion

Not everybody knows recursion

Not everybody knows recursion

• greg barton (unregistered) in reply to greg barton

fjf as this is turning into a programming less for you.

I wonder if this:

string FolderName = fileSystem.getFolderNameByID(NodeID);

ever occurred to you?

The operating system stores your entire file system as linked nodes. The fact they have a textual name associated with them does not in anyway mean that the operating system is using the textual representation. No changes needed to access files by a node ID. You are plain wrong.

• Sou Eu (unregistered) in reply to anon
Every business is owned or subsidized by the company? Where does he live, Naples?
I grew up in a small town where virtually all adults (over 95%) worked for the same company, including my own parents. That same company owned the shopping center, water company, and waste water treatment plant. If the company leaves, the town would die. Oh, this is in the good ol' US of A.
• jeff (unregistered)

The first thing you should know about recursion is that it involves recursion.

• greg barton (unregistered) in reply to greg barton

fjf I'm finished with this but you are correct 2^128 is an arbitrary limit. My bad. It's higher than the number of atoms in the solar system but I'll still accept your point. But I did mention Microsoft marketing...

• 008 (unregistered) in reply to Anon
Anon:
Recursion

re.curs.ion

Definition:

See recursion

I ran out of things to mark my page with. This is obviously a fault with the instructions. I quit.

• fjf (unregistered) in reply to greg barton

[quote user="greg barton"][quote user="fjf"]By confirming my points? Well, if you think so ...[/quote]

Ok google "INode file system structure" "or INode pointers". I'm not confirming your point as there is no major interface changes. The operating system stores INode numbers and INode pointers for traversing directory structures. This is how unix, linux, ntfs layout directory structures. It's how all your command line programs traverse directories, it's how the kernel traverses directories. So where is the major interface change?[/quote] In the part of my reply that you cut away:

chdir (const char *) -> chdir (some_integer_type)

Not major enough?

Same for open(), opendir(), stat() and many others (and whatever their Windows equivalents are).

Again, I'm talking about interfaces, not internal storage (which may be the lesser problem, though there are probably also a number of places where the full path is stored, such as the current directory). BTW, I know that in some cases there are alternative interfaces available, such as fchdir(), but my point is that most existing programs do use interfaces that pass path names and store path names in memory. They would all have to be changed massively to allow for path names larger than RAM size (more precisely, addressable virtual memory size).[/quote]

[quote user="greg barton"]Don't try and get into technical arguments if you don't know what your talking about it makes you look silly.[/quote] I'm trying to resist commenting on your apparent inability to distinguish between interface and internal storage, but can we calm down a little? As I said, I'm all with you about avoiding artifical limits, but I think you're focussing on a side-issue here. If you're serious about that, first write your own OS with no interfaces that expose path names in memory, including system library and utilities that make use of them, then we can talk about the merits of non-recursive directory traversals in those programs ...

• fjf (unregistered) in reply to greg barton
greg barton:
fjf as this is turning into a programming less(sic!) for you.

I wonder if this:

string FolderName = fileSystem.getFolderNameByID(NodeID);

ever occurred to you?

The operating system stores your entire file system as linked nodes. The fact they have a textual name associated with them does not in anyway mean that the operating system is using the textual representation. No changes needed to access files by a node ID. You are plain wrong.

I tried to discuss rationally, but your permanent ad-hominem attacks are getting boring.

So far the last time, hopefully:

string FolderName = fileSystem.getFolderNameByID(NodeID);

This very line would not work if the name is larger than the RAM size, since strings are stored in RAM, so you would have to change every program that uses it. No, you don't have to change the internal representation of node numbers in the OS, but you have to change the interface of getFolderNameByID() (or at least provide an alternative that perhaps retrieves the name into a designated file or so) and make programs use those new interfaces.

• PRM (unregistered) in reply to davedavenotdavemaybedave
davedavenotdavemaybedave:

For what it's worth, I have seen a million of something (enumerated), although I didn't count them. Anyone who's seen a palletload of anything small will have done - screws, sweets, sheets of paper, for example.

A teacher at my school made a book containing a million "X"s, to help us to visualise how much is a million. It would have been something like 250 pages at 80 cols x 50 rows.