Page 1 of 1
Infinite storage space????
Posted: Wed Nov 23, 2011 9:49 pm
by sdfgeoff
I made something cool on the computer, and wanted to show it to you. So I stuck it in a zip folder. It never zipped. It is impossible for it to zip!
What it is is 4 folders called "recursion 1" through "recursion 4" Inside each of these folders are 4 links to the other folders. You can go infinite layers deep into this file-system, thus there are an infinite number of folders, and thus an infinite amount of space on my computers hard drive!!!!
A bit like a klein bottle.
Unzipped it is 20kb. Zipped? Well, it says "getting file list" and then get's stuck. Eats up ram too.
So what is it good for, nothing really, except saying to a family member "I've lost a file, I know it's somewhere in this folder......"
For you guys on Linux you can repeat it easily, probably on other platforms too.
Re: Infinite storage space????
Posted: Wed Nov 23, 2011 9:51 pm
by Alter-Fox
Lol nice. It would be awesome if that actually could give you infinite storage space, too bad even on computers disk space is a physical thing.
Re: Infinite storage space????
Posted: Wed Nov 23, 2011 9:52 pm
by sdfgeoff
A word of caution here too. Delete it before running a file-system check. I imagine it would get stuck the same way the archive manager did.
Re: Infinite storage space????
Posted: Fri Nov 25, 2011 12:24 am
by Jeff250
I've also seen an analogous trick used to create gzip files that infinitely recurse *decompressing*. People use these kinds of tricks to DoS antivirus programs.
Re: Infinite storage space????
Posted: Fri Nov 25, 2011 3:45 pm
by Aggressor Prime
Hmmm, didn't work for me. I tried on Windows 7 and used WinRAR. There was no lockup and the file size was normal.
Re: Infinite storage space????
Posted: Sat Nov 26, 2011 2:16 am
by sdfgeoff
For once windows may be smarter than linux!
Actually it's just the zip tool. When I look at it using the "tree" terminal command, it realizes it's a loop and stops at the forth time through.
In windows I suspect that the links are really links (ie a physical file) rather than another reference/access point to the same folder.
Re: Infinite storage space????
Posted: Wed Nov 30, 2011 6:57 am
by snoopy
Did you make a hard link, or a symbolic link?
Re: Infinite storage space????
Posted: Wed Nov 30, 2011 1:37 pm
by sdfgeoff
Um, I remember there being two types of link, but I just right-click and "make link"
Oh, and something I read the other day made me think that a zip file when opened on windows can't have more than 7 parent directories. Any conformation for this?
Re: Infinite storage space????
Posted: Wed Nov 30, 2011 4:22 pm
by Jeff250
In linux, you can't hard link directories, only symlink them.
Re: Infinite storage space????
Posted: Wed Nov 30, 2011 10:54 pm
by snoopy
Jeff250 wrote:In linux, you can't hard link directories, only symlink them.
Nice, you learn something new every day.
Now, if I'm correct, the FS treats a symlink as it's own entity, so it really kinda the zip utility's bad for treating the symlink like a link instead of like a file.
Re: Infinite storage space????
Posted: Thu Dec 01, 2011 12:16 am
by Jeff250
Right--if you could hard link directories, then you'd have to check the inode of every directory you recurse. (Even with symlinks, if you wanted to recurse them, then you'd only have to check the path that symlinks point to to avoid cycles.)
Probably another reason you can't hard link directories is for symmetry with rmdir(). Normally, you can't rmdir() a directory with files in it. But what if you call rmdir() on a non-empty directory whose inode has multiple file system links? Whether you choose to allow that or not would be surprising in one situation or another. So that's another good reason to only allow out-of-band *sym*links for directories.
There are probably other oddities this would lead to as well.
Re: Infinite storage space????
Posted: Thu Dec 01, 2011 12:21 am
by Jeff250
And something more relevant to the original discussion, if you use tar, then it should preserve the symlink as a symlink inside the archive.