ChDir()

[timstring]

I tried this with various forms of the file path:

$file = "KathyStringHD/Users/tim/Downloads";
if(is_dir($file))
  {
  echo ("$file is a directory");
  }
else
  {
  echo ("$file is not a directory");
  }

... and the routine returns a negative

I also have tried:

./../../Downloads

And various forms of periods

Need an education.

tim

[Derokorian]

$file = "KathyStringHD/Users/tim/Downloads"; 

This line says, from the current working directory, add the string "KathyStringHD/Users/tim/Downloads". given where you said the script is that means its trying to look for "KathyStringHD/Users/tim/Sites/DispatchReports/KathyStringHD/Users/tim/Downloads" What you probably want to do is start the path with a leading "/" which means from the root, this is the full path to something.

[bradgrafelman]

And you also probably want to remove "KathyStringHD" from the path altogether, since I'm betting this is just some friendly name you've given the hard drive and actually has no bearing on file paths whatsoever.

[timstring]

ADMIN: Give the author of a post the power to delete that post. Would save me a lot of ducks.

This returned a positive result:

$file = "../../Downloads"; //works
if(is_dir($file))
  {
  echo ("$file is a directory<br /><br />");
  }
else
  {
  echo ("$file is not a directory");
  }

But, this:

   $file = "../../Downloads/Texoma_01_28_14.csv";
if(is_file($file))
  {
  echo ("$file is a regular file");
  }
else
  {
  printf("Errormessage: %s\n", $mysqli->error);
  }

  die();

returns Error 15, and I get a gazillian hits when trying to search for the error code.

Point me in the right direction

[bradgrafelman]

timstring;11037877 wrote:

Returns a '1' without returning either string. I do not understand

It's a result of operator precedence (and/or associativity). PHP is first evaluating the logical statement:

("$file is not a regular file") or die("can not find file" . mysql_error())

which becomes TRUE (since a non-empty string evaluates to TRUE, thus there's no need to even evaluate the die() statement), and boolean TRUE is represented as the string "1".

Since it makes no sense to use the "or die" construct or the contents of the die() (where on earth did MySQL come from all of a sudden?), try getting rid of that altogether. Of course, since we know this branch is getting hit, you already have your answer - "../../Downloads/Texoma_01_28_14.csv" doesn't appear to be a file according to PHP.

[timstring]

see edited post.

[bradgrafelman]

Again, I thought we were talking about file system problems, so why the reference to MySQL? Seems like you're trying to diagnose a broken toilet by asking a mechanic what's wrong with your car engine.

To get more appropriate diagnostic info, try using [man]is_readable/man on the Downloads directory itself to verify that PHP can read it (not just see that it exists). If that works, try doing a [man]glob/man on a pattern like ""../../Downloads/." to see if PHP can list the files in the directory. If that works... then try doing a [man]var_dump/man on the array that glob() returns and copying/pasting the array item that corresponds to the file you're attempting to use above.

[timstring]

thanks for the tip. Downloads turned out to be readable, but none of the files were. So, back to the basics. The group permissions were off. I re-provisioned the folder for Group set to Everyone & Everyone set to full access. That worked. My question now is: What should the permissions be for the folder so I can keep it away from prying eyes?

thanks as always,
tim

[dalecosp]

Depends on who the prying eyes are. ;-)

Everyone set to full access

Obviously that won't.

http://daleco.biz/help/unixhelp/tasks/access_permissions.html

[sneakyimp]

timstring;11037895 wrote:

thanks for the tip. Downloads turned out to be readable, but none of the files were. So, back to the basics. The group permissions were off. I re-provisioned the folder for Group set to Everyone & Everyone set to full access. That worked. My question now is: What should the permissions be for the folder so I can keep it away from prying eyes?

I would strongly advise better acquainting yourself with file permissions concepts. It will really pay off in the long run.

An important concept in this case is that your PHP script runs as some user. Not clear to me whether you are running it from a web server or some other way. To find out which user is running the script, I usually put this in the script:

passthru("whoami");

That user might be tim or it might be www-data or it might be apache or something else.

Another important concept is that file permissions on unix-like file system such as linux or OSX let you specify for each directory or file the permissions for the owner of the file, the permissions for some group of users, and the permissions for any user on your machine, possibly including users that are not really users at all but things like mysql or ssh or other daemon processes running on your machine.

For a particular to access a file, there are a few possible ways to grant access:
1) make that user the owner of the file. this is often not a feasible solution
2) either change the file's group to some other group of which this user is a member OR add this user to the group currently assigned to the file. This might be a little confusing until you realize that every file has a group assignment which may be the owner, it may be some other user, or it could be some other group like wheel or a custom group you create like mygroup.
3) grant permission on the file to everyone. this is not really safe. you generally should not ever grant write permission to everyone and you should never grant read permission to everyone if the file has any data that is remotely sensitive.

[timstring]

I am beginning to understand. Why do the terminal commands work and the PHP ones don't?

passthru("whoami")

yielded '_www'

So: I added me to the group:

 sudo dseditgroup -o edit -a tim -t user _www

no errors

when I try this in PHP, nothing happens:

$OutputPath = "/Users/tim/Sites/DispatchReports/" . $OutputFile;
$UserName = 'tim';
chown($OutputPath, $UserName);

Changing permissions via:

chmod($OutputPath, 0775);

has the desired effect. I can read and write the file as a member of the group.

So, why does the 'chown' statement not work? Is this something practically impossible and not worth the effort?

tanksalot

[dalecosp]

timstring;11038029 wrote:

So: I added me to the group:

Pronoun alert!

Me who? Me 'tim'? Or me "_www"?

You say a ways above here, "the group permissions were off".

Generally, the best policy is allow user-level access first; you only need to mess with group permissions when you have more than one user that needs access.

As to why "chown" doesn't work, not certain, but generally you've got to be root or something with some power to start giving files away.

Ah, indeed:

php.net/chown wrote:

Only the superuser may change the owner of a file.

[sneakyimp]

timstring;11038029 wrote:

I am beginning to understand. Why do the terminal commands work and the PHP ones don't?

passthru("whoami")

yielded '_www'

So: I added me to the group:

 sudo dseditgroup -o edit -a tim -t user _www

no errors

I'm not exactly sure what dseditgroup does, but it doesn't really sound like the right solution to me.

timstring;11038029 wrote:

when I try this in PHP, nothing happens:

$OutputPath = "/Users/tim/Sites/DispatchReports/" . $OutputFile;
$UserName = 'tim';
chown($OutputPath, $UserName);

Did you bother checking the result of chown? It's been my experience that one must have admin/root/wheel permissions to chown anything. Trying to do it as an ordinary user (or as user _www) doesn't work. You should always check the result of your executed commands in case there was an error.

timstring;11038029 wrote:

Changing permissions via:

chmod($OutputPath, 0775);

has the desired effect. I can read and write the file as a member of the group.

Yes of COURSE you can edit a file if any of the following is true
a) you are the file owner and the owner has write permissions on the file
b) you are a member of the group assigned to the file and the group is allowed write permission on it
c) the file permits write permission by everyone.

The trick, as always, is to set the permissions so everyone can write the file that must do so and everybody else cannot.

[timstring]

Did you bother checking the result of chown?

Actually, I did. When I turned on the error reporting, I got:

chown(): Operation not permitted in /Users/tim/Sites/DispatchReports/GenerateInTime.php on line 291

also, with more digging, I found out that only "root" can be set as the owner of the file. As I asked, "... is it too much trouble?" The conclusion for me is 'Yes" for the moment. I've got bigger problems to solve first.

b) you are a member of the group assigned to the file and the group is allowed write permission on it

Since the owner & group are "_www", I added myself to that group and then used "chmod" to give w/r/x permissions to the group.

I know, not an ideal setting, but it works for now.

Oh, yeah, I can't get the error reporting to turn off in spite of:

error_reporting(0);
ini_set('display_errors', FALSE);
ini_set('display_startup_errors', FALSE);

[sneakyimp]

timstring;11038185 wrote:

Actually, I did. When I turned on the error reporting, I got:

chown(): Operation not permitted in /Users/tim/Sites/DispatchReports/GenerateInTime.php on line 291

I find it odd that chown would have returned success if it didn't actually work. I usually follow up any permission-related attempts in PHP with a call to [man]is_readable[/man] or [man]is_writable[/man] to see if things worked.

timstring;11038185 wrote:

also, with more digging, I found out that only "root" can be set as the owner of the file.

I suspect you are getting the picture but would like to correct this statement all the same. Only "root" user can change the ownership of files using chown, but the ownership of the file (and its group) can be set to pretty much any user on the system as long as the user performing the chown operation has sufficient permission level. NOTE: that your webserver (user _www) could successfully use the chown command if you were to add this user to the sudoers list or the wheel group. I would not recommend this at all as it is extremely unsafe. Just trying to clean up confusion about permissions a bit...

timstring;11038185 wrote:

As I asked, "... is it too much trouble?" The conclusion for me is 'Yes" for the moment. I've got bigger problems to solve first.

I can respect that. We all have to make a living.

timstring;11038185 wrote:

Since the owner & group are "www", I added myself to that group and then used "chmod" to give w/r/x permissions to the group.

I know, not an ideal setting, but it works for now.

I suppose it's not totally awful you are part of the www group. Just a little weird. I probably would have created a new group, e.g., "writers_group" and would add myself and _www user to that group and then chown (or chgrp) all the relevant files to that group and then chmod them 664 (or 775 for directories).

timstring;11038185 wrote:

Oh, yeah, I can't get the error reporting to turn off in spite of:

error_reporting(0);
ini_set('display_errors', FALSE);
ini_set('display_startup_errors', FALSE);

Did you restart the web server? Every time you change php.ini, you need to restart the web server.