Simple Flatfile Recording?

[Element]

I was wondering if it is possible to have a simple flatfile recording system that will check the images reverse IP and compare it with a flatefile that contains the reverse ip of a user on as the first part to seperate users images which could be seperated in each line by a | and use just the images name. I'm not good with flatfile stuff, I did MySQL first lol... I also wanted to make a new folder for each user that uploads a image based off like a field or something but I think I can get that unless in involvse the question I just asked. o.o;

[Fou-Lu]

IP isn't a trustable solution for recording comparisons with php.
I would recommend instead creating a user based system with login features and recording it by userid instead. I don't know exactly what it is your doing either.
Creating a directory for each user is tricky as well. I mean, the php for it is quite simple, but I have found that sites with large amounts of users each containing their own directory tended to crumble the filesystem. I don't know why this happens, but the only real usable solution was to create directories within these directories for each character of their userid:
userid = 14
Filepath: /images/1/4/
userid = 188
Filepath: /images/1/8/8/
See what I mean? It still gets quite difficult to navigate, but I have found this method to be more stable than using filepaths for /images/14/ and /images/188.
Anyway, if you have mysql, use it instead, it would be a far more simplistic task to do.

[marek_mar]

I have found this method to be more stable than using filepaths for /images/14/ and /images/188.

Why??

[Fou-Lu]

I don't know why this happens...

Apparently some systems cannot handle a directory for each userid when it exceeds 30,000. As I mentioned, this would only be a problem when it comes to large sites. I'll see if I can find some documentation, or someone whom knows more of the reasons for this.

[marek_mar]

30,000 as in folder name or amount of folders? Anyways this seems odd to me. Why 30,000 and not limit to 8digits or something like that? As to the folder amount... it doesn't change no matter what.

[Fou-Lu]

Amount of subdirectories.
All I've found so far is that the older versions of the Solaris filesystem couldn't cope with subdirectories over ~32,768. So if you have 32,769 users with a subfolder of their own within path/userid, your filesystem would undoubtably crumble.
I'll see if I can track down some more info and add a couple of link as well.


Interestingly enough, solaris is only one of several systems which suffer from this affliction. Note, these all appear to be older versions of the software:
http://www.linux-mag.com/2002-10/jfs_01.html
http://www.clusterfs.com/faq.html#size-4

It appears to all be linked with the ext2/3 hashed directory code. Not that that makes any sense to me :p

[marek_mar]

But this cheat will only work if it only matters how many subdirectorys are in one directory "level" not all subdirs of a dir (I dunno which is the right one though).

[Fou-Lu]

You're right about that as well. I'm pretty sure it refers only to the child directories, not to the grandchildren. I found where I first learned this as well, its on my vBulletin 3.x (or rather, the site I co-administrate's vB). It mentions in default mode about this action, and how they needed to use the per character subfolders to cope.
In actual practice... you probably wouldn't need to ever worry about this, as all current records I've found mention that up to date systems (from within the last two years), are all capable of handling unlimited subdirectories. Unfortunatly, I'm not an OS guru so I don't know if *unlimited* is actually possible, or if there is an eventual limitation. Honestly though.. I'd probably still use the each character of the userid as a directory within a directory, simply for cleanliness. I cannot say for sure, as I've never handled a site with 32000+ members on it, I just figure it would be easier to navigate to the individual users folder - and undoubatly less memory intensive. If I'm looking at like, < 10000 users, I'd say a folder just after their userid would be perfect to have. Or even better... use mysql :)

[marek_mar]

FileSystems can limit databases too. That's why nobody uses FAT for servers. It's a lot harder to reach a limit on a decent FS though. (Maximum file size limitation)

[Fou-Lu]

FileSystems can limit databases too. That's why nobody uses FAT for servers. It's a lot harder to reach a limit on a decent FS though. (Maximum file size limitation)
Ah, good to know. That would be IIS for one correct?
Wow... we bastardized this thread, sorry about that mate

[Element]

Aha. Perhaps, instead, I should just put a index in the archives for images and use a MySQL based user system that records their images URLs, each user image being renamed to a 8 digit/char random setting. This possibly might take alot of stress away from server. Either that or store images via MySQL and out putting them in a PHP file and using mod_rewrite. Another even simpler way with easier compression. However I have heard SQL fusses over so much encoded data. I don't know, I'll play around with it. For now I just have http://shack-cafe.com/upload_file.scp