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.
Results 1 to 9 of 9
  1. #1
    Regular Coder
    Join Date
    May 2011
    Posts
    122
    Thanks
    23
    Thanked 0 Times in 0 Posts

    Trying to use unlink($pic);

    I am trying to learn the unlink(); use. Because I have a delete option and want to delete a file. The file is located @ (ex) image/daily_picdump_831_640_52.jpg

    How should I use it with unlink(image/daily_picdump_831_640_52.jpg); ? Because that doesn't work.

  • #2
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,979
    Thanks
    4
    Thanked 2,659 Times in 2,628 Posts
    That needs to be treated as a string, otherwise it will result in trying to unlink('.jpg');.
    Beyond that, image/ will refer to a subdirectory of where the executing script is. This is fine, as long as its where you expect to find the directory. Unlink will fail if it cannot find the file.

  • #3
    Regular Coder
    Join Date
    May 2011
    Posts
    122
    Thanks
    23
    Thanked 0 Times in 0 Posts
    Sorry, I don't fully understand.

    If I use the image/ (directory) where the images are, is fine correct?
    This is the code I use for unlink:

    PHP Code:
    $id $_POST['id'];
    $author $_POST['author'];
    $title $_POST['title'];
    $picloc $_POST['pic'];
    echo 
    'Thanks <div class="size"><font color="red">' .$author'</font></div>! We\'ve deleted that file that may of caused a ToS Obstruction!';
    mysql_query("DELETE FROM images WHERE id = '$id'"); 
    mysql_query("ALTER TABLE images AUTO_INCREMENT=$id");
    unlink($picloc); 
    $picloc obviously being image/daily_picdump_831_640_52.jpg

  • #4
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,979
    Thanks
    4
    Thanked 2,659 Times in 2,628 Posts
    This is different than your original description of usage.
    Assuming that $picloc is indeed valid location, then yes the above is fine. You can do this with a simple check for a file:
    PHP Code:
    if (is_file($picloc))
    {
        
    unlink($picloc);

    You can add output as well to indicate if the location is valid or invalid.

  • #5
    New Coder
    Join Date
    Apr 2010
    Posts
    55
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by Xaqa View Post
    Sorry, I don't fully understand.

    If I use the image/ (directory) where the images are, is fine correct?
    This is the code I use for unlink:

    PHP Code:
    $id $_POST['id'];
    $author $_POST['author'];
    $title $_POST['title'];
    $picloc $_POST['pic'];
    echo 
    'Thanks <div class="size"><font color="red">' .$author'</font></div>! We\'ve deleted that file that may of caused a ToS Obstruction!';
    mysql_query("DELETE FROM images WHERE id = '$id'"); 
    mysql_query("ALTER TABLE images AUTO_INCREMENT=$id");
    unlink($picloc); 
    $picloc obviously being image/daily_picdump_831_640_52.jpg
    Never ever code like that!!

    You are allowing the user to delete any file on your system! Obviously you need to verify that the variable is the one user has right to delete. If you have a proper database, you should only use variable id from post, verify the ownership and then get the actual location from the database. Then delete the file and database entry. Catch any error and show the correct message. Obviously the Linux permissions applies and your script may / may not be able to delete the file.

    You need to improve your logic, error handling, security etc by a large margin before doing any real live sites!
    Hosting Reviews and Discounts: Bluehost Coupon and Hostmonster Coupon

  • #6
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,091
    Thanks
    51
    Thanked 506 Times in 493 Posts
    To add to it, resetting the auto incrementing ID isn't a good idea either. It can break things. The very idea of the auto increment is that you never worry about the number in that field as it never changes but new records get their own number which is never recycled. When you delete a record you just leave a numeric gap there. If you're worried about finding the next record you simply use a clever SQL technique:

    order by id asd/desc - which will return the next/previous records irrelevant of the records id number.
    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!

  • #7
    Regular Coder
    Join Date
    May 2011
    Posts
    122
    Thanks
    23
    Thanked 0 Times in 0 Posts
    If I have id's such as:

    35
    36
    37

    And I delete 36, it will have a gap indeed. But when I try and upload to the database it would update with that gap there. So I thought I would do the auto increment, i guess not.

  • #8
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,979
    Thanks
    4
    Thanked 2,659 Times in 2,628 Posts
    Quote Originally Posted by Xaqa View Post
    If I have id's such as:

    35
    36
    37

    And I delete 36, it will have a gap indeed. But when I try and upload to the database it would update with that gap there. So I thought I would do the auto increment, i guess not.
    No, the sequence for the auto_increment is always known by the dbms. It only resets when you alter the type or fully truncate the table in mysql. This is not a problem, except you are limited to about 4 billion records
    It is much better to never touch the surrogate, or if you really want never use a surrogate at all. Properly designed databases can get away without ever needing one, but sometimes it becomes complicated with multiple composite keys. I'd rather refer to record 516 (referring to user fou-lu with a non-threaded forum display with 10 records at a time) then user=fou-lu AND configuration=display AND display=10 for example.

    Edit:
    BTW, I should mention if you are regularly deleting records, you may have a normalization issue on your hand. For something like a blog post where the deletion is done to free up disk space, you may want to consider not using a surrogate key at all.

  • #9
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,091
    Thanks
    51
    Thanked 506 Times in 493 Posts
    Quote Originally Posted by Xaqa View Post
    If I have id's such as:

    35
    36
    37

    And I delete 36, it will have a gap indeed. But when I try and upload to the database it would update with that gap there. So I thought I would do the auto increment, i guess not.
    Thats mysql being disk space efficient. Yes in phpmyadmin you will notice that the rows are recycled but if you are using auto_increment the number will not be recycled - it will be the next highest number of the current highest number in that column.

    Say you have records:
    35
    36
    37


    You then deleted 36 and are left with:
    35

    37

    When you next insert a record the next auto_increment value will be 38 but mysql will recycle the deleted space:
    35
    38
    37

    To take care of this, mysql has the optimise table command which basically forces it to go through the table and remove unused spaces before they're recycled. I'm not sure if it re-orders recycled spaces - I've never actually looked at that.

    The main point is, that whether or not that row has been recycled, its id will be unique and one that has never been used before. As Fou says there is no issue with this other than the maximum being reached (good luck getting to 4 bil).
    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!


  •  

    Posting Permissions

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