Thread

@xwero - reading and writing (into/from variable) uploaded file might even kill the application execution if the uploaded file is too big and exceeds allowed php memory usage. In general, for file copying/moving is better to use PHP’s filesystem functions.
Using tempnam is a little bit tricky - if the destination directory doesn’t exist, temp file will be created in the PHP’s temporary directory without warning or any error thrown…

reading and writing (into/from variable) uploaded file might even kill the application execution if the uploaded file is too big and exceeds allowed php memory usage. In general, for file copying/moving is better to use PHP’s filesystem functions.

i’m not sure what you are saying exactly. As i interpret it “reading and writing (into/from variable) uploaded file” is move_uploaded_file and “PHP’s filesystem functions” is tmepnam, right?

I think if you are talking about big files, there will always a risk of exceeding the available memory but if you have to transport the content from one function to another, file_puts_contents(file_gets_contents($file)), will consume more memory than using only one function for the job, but i could be wrong.

I meant that file contents moving or copying by getting it all into some variable, isn’t the best way to do it. Usually memory_limit in php is 8M or 16M which is OK. But if you are dealing with large files (e.g. 8+M), it is not appropriate to copy files in such a manner. It seems that we are talking about the same thing, but in different ways 😊
Nonetheless, my main point was that if someone is willing to use tempnam, must be aware of it’s behavior when the destination folder doesn’t exist. Sorry for the confusion…

@xwero—Yes, put tempnam in your hip pocket.  It is great for allowing users to create file names of their choosing while relieving you of all this string manipulation.  Simply xref the random file name to the string they provide via an input form during file creation.

I suppose you’re correct, for file uploads this might not be optimal. But lets just apply the same ‘Randy’s too stupid to make this complicated principle’.  Here is my new proposal to completely prevent having to write ANY of the string manipulation code AT all.  So I should handily win this little competition 😉.

—-
Use the cross reference idea but build a cross reference based upon PHP’s temporary file name.  Just don’t move the file from the temp file location.  Leave it there.  Refer to it with user’s file “string” rather than file “name”. PHP automatically radomizes the names (and manages the randomization internally) in the temp folder.  Just leave them in there to avoid collisions.

Problem solved.

I thought the temp location was cleared to prevent the hard disc from filling up with temp files so permanently storing the files there would be a bad idea.

If you store files without an extension it’s going to be hard to separate different filetypes if needed.

If you are looking for a unique filenames check out uniqid.

I think your solutions are not going to stand the test of time.

@xwero—work with me here.  His goal was to provide an operating system compliant string that he could use for the file name.  My goal is to accomplish that with no code <grin>.

...so permanently storing the files there would be a bad idea.

You’re going to store it someplace.  Realistically your application ‘MAY’ require you to move it. OK, move it if you want.  Here’s the point.  If you use the name that PHP has already provided, then there is no reason to go through the string manipulation…

If you store files without an extension it’s going to be hard to separate different filetypes if needed.

This is the precise reason for maintaining the cross reference I referred to earlier. This is a common practice. Store the user supplied “file name” complete “with the extension” along with the randomized file name automatically generated by PHP.  Store this in your favorite storage mechanism (ini file, XML, DB, etc.).  If you need to know the extension, simply look it up!

I think your solutions are not going to stand the test of time.

On the contrary my friend.  These are in play everywhere and have been before you and I were hacking code.  (Maybe even mean before you were born?).  I think sometimes we just think we have to “write a new class and override the world” to echo “Hello World!” these days.

—-

PHP does SO much for us in its core (and it does it so blazingly fast being written in C and all).  We should just let it do as much as it can for us.  The problem arises when we don’t know about all it’s capabilities.  Like CI…I just learned CI has a method csv_from_result() in the DB_util class.  I didn’t have a clue.  I suppose that might be useful someday.

I’m beginning to see your point, it still feels alien to me instead of searching the actual files searching the database for file properties but that is what databases are made for.

One thing that still not convinces me is when the files are publicly displayed. According to me they will have to be generated in their public form. If you start caching those somewhere you have them stored in two places meaning their space on the disc is doubled. I think like always the solution lays in the middle.

But you earned the non code award 😉

Great :coolcheese: blow off one party popper! Now… Let’s continue about this idea of having two files floating around…because you don’t have to.

I don’t understand your concept of the “public form” verses some non-public form I suppose. Think about, or research, how INodes work in a unix/linux operating system.  I suppose your concept of the “public form” would be refering to a file in unix file system by its file name while the non-public form of this would be how the operating system refers to the file by its inode.  Unix uses a cross reference to keep the two in sync.  Thereby making the “end user happy with silly words that humans like” and keeping the system happy with binary things (32 bit hex actually) the system likes to deal with.  This cross reference is very efficient, but there certainly isn’t two copies of the file on disk just to satisfy two perspectives.

Can you help me understand further?