Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 17
  1. #1
    Regular Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    939
    Thanks
    21
    Thanked 0 Times in 0 Posts

    How to Delete a File?

    Is there a way that PHP can delete a file off of my server?

    Here is my problem...

    A few years ago I wrote a script to allow someone to upload a picture to their profile to serve as a thumbnail.

    But I only ever allow ONE photo per profile.

    The problem is that if a user uploads a new photo, then the old one is still sitting in my "uploads" directory.

    (And just during testing locally, I have hundreds of orphaned photos. God help me if I didn't fix this before turning the world on my website!!)

    So, is there a way that I could modify my script so that when someone uploads a new photo, my script would find the old photo and physically remove it from the server??

    Sincerely,


    Debbie

  • #2
    New Coder
    Join Date
    Jun 2013
    Location
    The Republic of Texas
    Posts
    29
    Thanks
    0
    Thanked 6 Times in 6 Posts
    You haven't given enough info to be able to "find the old photo", but:

    PHP Code:
    unlink('/path/to/image.ext'); 
    will delete it.

  • #3
    Master Coder mlseim's Avatar
    Join Date
    Jun 2003
    Location
    Cottage Grove, Minnesota
    Posts
    9,371
    Thanks
    8
    Thanked 1,075 Times in 1,066 Posts
    Unlink is the command: http://php.net/manual/en/function.unlink.php

    But figuring out which one(s) to delete is another issue.
    You may be able to do something with file dates?

    To find old photo when a new one is uploaded, you need to know the name of both files.

    Or maybe overwrite the old one with the new one ... giving it the same filename?

  • #4
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,978
    Thanks
    4
    Thanked 2,659 Times in 2,628 Posts
    You can use the unlink function.
    Be careful with it though, anywhere this user has privilege it can delete, so obviously don't execute this code using an administrative (ie: watch your cron as well) account, or system account.

    Finding orphans is a matter of iterating a directory and seeing if its existence is required according to the dbms. Although you can use all sorts of trickery, the easiest way to do this is simply using a local script (php or otherwise), and simply checking each file one by one to a prepared statement.

    Edit:
    Look like I was beaten to it :P
    PHP Code:
    header('HTTP/1.1 420 Enhance Your Calm'); 

  • #5
    Senior Coder
    Join Date
    Sep 2010
    Posts
    1,899
    Thanks
    15
    Thanked 226 Times in 226 Posts
    In the future you could make it where the uploaded photo has their user name, and when they upload a new one the old one get overwritten with the new one, which is default for files that are uploaded with the same name.
    Welcome to http://www.myphotowizard.net

    where you can edit images, make a photo calendar, add text to images, and do much more.


    When you know what you're doing it's called Engineering, when you don't know, it's called Research and Development. And you can always charge more for Research and Development.

  • #6
    Regular Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    939
    Thanks
    21
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Fou-Lu View Post
    You can use the unlink function.
    Be careful with it though, anywhere this user has privilege it can delete, so obviously don't execute this code using an administrative (ie: watch your cron as well) account, or system account.
    I haven't looked at this old script yet, so my question may have been premature.

    I know I spent an *enormous* amount of time 2 years ago writing a "bullet-proof" Upload Script.

    Am I on a suicide mission using unlink()???

    (Would be a real b * tch if some hacker way able to delete every file on my server!!!)

    Sincerely,


    Debbie

  • #7
    Regular Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    939
    Thanks
    21
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by DrDOS View Post
    In the future you could make it where the uploaded photo has their user name, and when they upload a new one the old one get overwritten with the new one, which is default for files that are uploaded with the same name.
    As just mentioned, I will have to get back into my code before I can comment a whole lot, but it seems to me that I hashed the Filename for some reason...

    Then I stored the File with Hashed Filename in my "uploads" folder, and I put the Filename in the Member's record for reference.

    Sincerely,


    Debbie

  • #8
    New Coder
    Join Date
    Sep 2013
    Posts
    41
    Thanks
    0
    Thanked 1 Time in 1 Post
    Try out with the below two examples, it has worked fine for me:

    1.<a href="http://sitename.com/modify.php?delete={image}">Delete</a>

    2.unlink(Yii::app()->basePath.'/../images/uploaded/'. $oldfile);

    Hope this helps.

  • #9
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,089
    Thanks
    51
    Thanked 506 Times in 493 Posts
    Quote Originally Posted by doubledee View Post
    Am I on a suicide mission using unlink()???
    Don't delete it them. Just replace it.

    Don't use files on disk because if they accidentally get deleted or you rollback your database, your database records may not match the files on disk that you have.

    Instead, keep the avatars in the database in a blob field. If the user decides to update then you simply run an update with the new file being inserted into the blob. That way everything is kept nice and tidy in one place. IF you roll back the table for whatever reason then everything remains not broken

    Meanwhile your user has never called the unlink command and the worst they've done is to overwrite their old file.

    Right.. now I'm going to run for cover before the questions, bold, italics and underlining comes my way
    My helpful sig is on vacation trying to loose some weight. It got a bit fat and caused a few problems but it will be back at some point!

  • #10
    New Coder
    Join Date
    Jun 2013
    Location
    The Republic of Texas
    Posts
    29
    Thanks
    0
    Thanked 6 Times in 6 Posts
    Quote Originally Posted by priyankagound View Post
    Try out with the below two examples, it has worked fine for me:

    1.<a href="http://sitename.com/modify.php?delete={image}">Delete</a>

    2.unlink(Yii::app()->basePath.'/../images/uploaded/'. $oldfile);

    Hope this helps.
    What?!?! What in the OP make you think they use YII? Also, don't ever use GET to delete, use POST.

    Quote Originally Posted by tangoforce
    Don't use files on disk because if they accidentally get deleted or you rollback your database, your database records may not match the files on disk that you have.

    Instead, keep the avatars in the database in a blob field. If the user decides to update then you simply run an update with the new file being inserted into the blob. That way everything is kept nice and tidy in one place. IF you roll back the table for whatever reason then everything remains not broken
    One of the very few posts I have seen recommending to not store files in the filesystem but in the DB. Hmmm... I heartily disagree. The filesystem is for files.

  • #11
    Regular Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    939
    Thanks
    21
    Thanked 0 Times in 0 Posts
    Tango,

    I spent all of last night staring at my screen getting confused what I want to do with this area of my website.

    May table it for now.

    But in the background I'll keep scheming and researching, so I'll keep threads like this one going...


    Quote Originally Posted by tangoforce View Post
    Don't delete it them. Just replace it.
    Didn't get to my code last night, but IIRC, I took the file and hashed it, because I have a business rule that "Only one unique image per the system."

    IIRC, the hashing of the file creates a unique hash based on the file.

    So, if I hashed that picture you sent me of you in your Superman outfit and *tights*, then no one else could upload that same physical image.

    That is key to me, because I hate websites where everyone uses the same pics of their favorite model.

    Anyways, I'm rambling here a bit...

    So that creates a conflict with your "Just replace one image for the next".

    My business rule is unlikely to change.

    Is there a way to "have it both ways" so I can take your advice but not ditch my business rule?



    Quote Originally Posted by tangoforce View Post
    Don't use files on disk because if they accidentally get deleted or you rollback your database, your database records may not match the files on disk that you have.

    Instead, keep the avatars in the database in a blob field. If the user decides to update then you simply run an update with the new file being inserted into the blob. That way everything is kept nice and tidy in one place. IF you roll back the table for whatever reason then everything remains not broken
    All very valid points, but conventional wisdom says "DO NOT store images in your database!!!"

    (You realize this is still probably a big "religious debate", right?)


    My fear is that if I have 10,000 or 100,000 Members, your advice could bring my database to its knees...

    Care to explain why that wouldn't be an issue?


    Quote Originally Posted by tangoforce View Post
    Meanwhile your user has never called the unlink command and the worst they've done is to overwrite their old file.
    True.


    Quote Originally Posted by tangoforce View Post
    Right.. now I'm going to run for cover before the questions, bold, italics and underlining comes my way
    Ha ha.

    Hey, I was *pretty good* in THIS post...

    Sincerely,


    Debbie

  • #12
    Master Coder mlseim's Avatar
    Join Date
    Jun 2003
    Location
    Cottage Grove, Minnesota
    Posts
    9,371
    Thanks
    8
    Thanked 1,075 Times in 1,066 Posts
    In your database for each user, you must be storing the filename of their avatar? What if once a week, you had a CRON job that went through the directory and removed any images that were not part of the user database (remove orphan images)?

    During that CRON job, if any of the images have the same exact byte size, they are probably the same image. Those would be flagged to later see if they are in-fact the same "Superman In Tights" image used by two different people.

  • Users who have thanked mlseim for this post:

    doubledee (10-22-2013)

  • #13
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,089
    Thanks
    51
    Thanked 506 Times in 493 Posts
    Quote Originally Posted by doubledee View Post
    Tango,
    Debbie,

    Quote Originally Posted by doubledee View Post
    IIRC, the hashing of the file creates a unique hash based on the file.
    True however an MD5 hash is only 32 characters. At some point some other content may generate the same hash. The hash doesn't increment like a database table can, it's a fixed length and at some point, something somewhere will generate that very same hash (though not necessarily on your site / server).

    Quote Originally Posted by doubledee View Post
    So, if I hashed that picture you sent me of you in your Superman outfit and *tights*, then no one else could upload that same physical image.
    You promised to keep that quiet Now what are my two mates Fou-Lu and firepages going to think of me?

    Quote Originally Posted by doubledee View Post
    Anyways, I'm rambling here a bit...
    Just the norm then

    Quote Originally Posted by doubledee View Post
    So that creates a conflict with your "Just replace one image for the next".
    No not really. Like I said, replace the blob and you won't need to *delete* anything or let the user run a script that can *delete* somthing.

    Quote Originally Posted by doubledee View Post
    Is there a way to "have it both ways" so I can take your advice but not ditch my business rule?
    It's quote possible that getting so carried away with my spandex-made superman uniform (and tights) that I've not quite grasped how your business rule would affect this. While stretching the tights to get my legs in, I vaguely remember you mumbling something about md5 hashes - which can also be stored in the same table / row with the appropriate blob. Remember though, resizeing an image by just one pixel will generate a totally different md5 hash.

    Quote Originally Posted by doubledee View Post
    All very valid points, but conventional wisdom says "DO NOT store images in your database!!!"
    I think there is a 'fear' or it myself amongst web developers but in many other languages it's common to store images in a database table. When it comes to websites though, people frown on the idea and think its a terrible idea.

    Quote Originally Posted by doubledee View Post
    My fear is that if I have 10,000 or 100,000 Members, your advice could bring my database to its knees...

    Care to explain why that wouldn't be an issue?
    For a start the server isn't running a lot in the way of graphics meaning the processor doesn't spend half it's time refreshing the form on your desktop and instead can burn those cycles doing 'system' stuff instead. Then you have to remember that most servers have superior CPU power over a desktop PC and can pick out a record from a table in a split second.

    Quote Originally Posted by doubledee View Post
    Hey, I was *pretty good* in THIS post...
    Yeah but you just revealed to my two biggest fans that little secret we had

    Right.. with that said, I must fly...

    Last edited by tangoforce; 10-22-2013 at 07:27 PM.
    My helpful sig is on vacation trying to loose some weight. It got a bit fat and caused a few problems but it will be back at some point!

  • #14
    Regular Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    939
    Thanks
    21
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by mlseim View Post
    In your database for each user, you must be storing the filename of their avatar?
    Right.


    Quote Originally Posted by mlseim View Post
    What if once a week, you had a CRON job that went through the directory and removed any images that were not part of the user database (remove orphan images)?
    I had this same exact idea last night!!

    (I have no idea how to do a "CRON job" or what it stands for, but I have heard of them at work.)


    Quote Originally Posted by mlseim View Post
    During that CRON job, if any of the images have the same exact byte size, they are probably the same image. Those would be flagged to later see if they are in-fact the same "Superman In Tights" image used by two different people.
    You lost me on this last part.

    What I was thinking as a "Plan B" was this...

    - TangoForce uploads his latest, and proudest "Superman in Tights" photo. (The ones where he finally got that annoying *stain* out...) *wink wink* *nudge nudge* *wink wink*

    - My upload script does its like 15 checks to make sure it isn't an evil malware file.

    - My script then uses the hash_file function - or maybe there is a newer, better function?! - to take this *unique* photo of Tango, and create a corresponding filename.

    - My script renames "TangoInSupermanTights.png" to "0987634183976.png" and saves it to the "uploads" directory in my Web Root.

    - My script then stores the Filename "0987634183976.png" in Tango's Member Record in the database. (This will be used to *point* back to the physical Image File in the "uploads" directory.)

    - If Fou-Lu tries to use his copy of Tango's picture, my script should prevent that, so no dups there.

    - If the following week, Tango is feeling more mellow, and he decides to change his Profile Picture with "TangoOnParkBench.png", my script does the same process as described above, but the original photo would linger...

    - So once a week, I would run a Query/Script/CRON (?) against the "member" table, and any Image Files that were NOT in that query-set, would get deleted - BY ME - from my "uploads" directory.

    The advantage being that "I" am in charge of what gets deleted, and a casual hacker couldn't get into an Upload script with unlink() in it, and delete everything!!!

    And, if I modifed my upload script to store Members' Photos OUTSIDE OF THE WEB ROOT, then that should add even more protection, right??

    Anyways, that was my "Plan B" idea, since I don't trust my code using unlink()...

    Sincerely,


    Debbie

  • #15
    Master Coder mlseim's Avatar
    Join Date
    Jun 2003
    Location
    Cottage Grove, Minnesota
    Posts
    9,371
    Thanks
    8
    Thanked 1,075 Times in 1,066 Posts
    I thought you said something about not liking several people to upload the same popular avatar. You would rather everyone use a unique avatar. So, if Tango uploaded Superman and the filename was changed ... Then I uploaded the same Superman with my own filename, the script would notice that the filesize of my avatar is exactly the same as Tango's. One would assume that I uploaded the same image as Tango, but with a different filename. I'm not sure of the odds that two different graphic images would have the same exact filesize (in bytes). Both of us using the same avatar image is against your "rules", so I would be asked to change it.


    EDIT:
    And the CRON job to delete unused photos would still use UNLINK. The CRON is a scheduler that executes one of your PHP scripts at a given time. The idea of images in their own sub-directory is a good idea.



    .
    Last edited by mlseim; 10-22-2013 at 10:37 PM.


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •