fopen - append works, write fails (but file is truncated)
Hans Fredrik Nordhaug
files. The subject says it all - I can add that both the directory
and the file is wordwritable. This happens on a (quite good) free
hoster in Norway which doesn't use safe mode, running PHP 5.1.6 as the
PHP info below shows ...
Test it at:
http://home.no.net/moldevbk/fopen-test/?mode=w (write - fails)
http://home.no.net/moldevbk/fopen-test/?mode=a (append - ok)
http://home.no.net/moldevbk/fopen-test/p.php - PHP info
http://home.no.net/moldevbk/fopen-test/fopen-test.phps - source code of test script.
I have searched the web and usenet, but not found this problem
mentioned before. I do realize that I can work around the problem by
truncating the file first and then appending to the empty file - but
that is ugly as ...
Regards, Hans
--
+ It's GNU/Linux, not Linux -> http://www.gnu.org/gnu/linux-and-gnu.html
+ Support the Free Software Foundation -> http://member.fsf.org/
+ Become an Open Directory Project Editor -> http://dmoz.org/
david...@techie.com
> I'm trying to write to a file in the current directory - no remote
> files. The subject says it all - I can add that both the directory
> and the file is wordwritable. This happens on a (quite good) free
> hoster in Norway which doesn't use safe mode, running PHP 5.1.6 as the
> PHP info below shows ...
>
>
> I have searched the web and usenet, but not found this problem
> mentioned before. I do realize that I can work around the problem by
> truncating the file first and then appending to the empty file - but
> that is ugly as ...
>
> Regards, Hans
>
> --
> + It's GNU/Linux, not Linux ->http://www.gnu.org/gnu/linux-and-gnu.html
> + Support the Free Software Foundation ->http://member.fsf.org/
> + Become an Open Directory Project Editor ->http://dmoz.org/
Just curious if instead of sending fopen w for the mode using wb? I
am not sure if that will make any difference or not, but might make it
work.
david...@techie.com
> On Jul 27, 12:00 pm, Hans Fredrik Nordhaug <han...@gmail.com> wrote:
>
>
>
>
>
> > I'm trying to write to a file in the current directory - no remote
> > files. The subject says it all - I can add that both the directory
> > and the file is wordwritable. This happens on a (quite good) free
> > hoster in Norway which doesn't use safe mode, running PHP 5.1.6 as the
> > PHP info below shows ...
>
>
> > I have searched the web and usenet, but not found this problem
> > mentioned before. I do realize that I can work around the problem by
> > truncating the file first and then appending to the empty file - but
> > that is ugly as ...
>
> > Regards, Hans
>
> > --
> > + It's GNU/Linux, not Linux ->http://www.gnu.org/gnu/linux-and-gnu.html
> > + Support the Free Software Foundation ->http://member.fsf.org/
> > + Become an Open Directory Project Editor ->http://dmoz.org/
>
> Just curious if instead of sending fopen w for the mode using wb? I
> am not sure if that will make any difference or not, but might make it
>
> - Show quoted text -
If you set the permissions on the folder you are attempting to save to
to chmod 707 you should be able to write the file.
david...@techie.com
> files. The subject says it all - I can add that both the directory
> and the file is wordwritable. This happens on a (quite good) free
> hoster in Norway which doesn't use safe mode, running PHP 5.1.6 as the
> PHP info below shows ...
>
>
> I have searched the web and usenet, but not found this problem
> mentioned before. I do realize that I can work around the problem by
> truncating the file first and then appending to the empty file - but
> that is ugly as ...
>
> Regards, Hans
>
> --
> + It's GNU/Linux, not Linux ->http://www.gnu.org/gnu/linux-and-gnu.html
> + Support the Free Software Foundation ->http://member.fsf.org/
> + Become an Open Directory Project Editor ->http://dmoz.org/
make sure the directory is set to allow group writing with permissions
set to 707. then it shoudl allow it to work.
Jerry Stuckle
707 is NOT a good one to use. It means anyone can write to the file.
And if it's not an executable file, you shouldn't have the execute bit on.
600 is great if the webserver is going to be the only one accessing it;
Otherwise you should use 660 with the proper group settings.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
david...@techie.com
> davidkru...@techie.com wrote:
> > On Jul 27, 12:00 pm, Hans Fredrik Nordhaug <han...@gmail.com> wrote:
> >> I'm trying to write to a file in the current directory - no remote
> >> files. The subject says it all - I can add that both the directory
> >> and the file is wordwritable. This happens on a (quite good) free
> >> hoster in Norway which doesn't use safe mode, running PHP 5.1.6 as the
> >> PHP info below shows ...
>
>
> >> I have searched the web and usenet, but not found this problem
> >> mentioned before. I do realize that I can work around the problem by
> >> truncating the file first and then appending to the empty file - but
> >> that is ugly as ...
>
> >> Regards, Hans
>
> >> --
> >> + It's GNU/Linux, not Linux ->http://www.gnu.org/gnu/linux-and-gnu.html
> >> + Support the Free Software Foundation ->http://member.fsf.org/
> >> + Become an Open Directory Project Editor ->http://dmoz.org/
>
> > make sure the directory is set to allow group writing with permissions
> > set to 707. then it shoudl allow it to work.
>
> 707 is NOT a good one to use. It means anyone can write to the file.
> And if it's not an executable file, you shouldn't have the execute bit on.
>
> 600 is great if the webserver is going to be the only one accessing it;
> Otherwise you should use 660 with the proper group settings.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> ==================- Hide quoted text -
>
> - Show quoted text -
You are right 707 wouldn't be a good one to use on a production
server, but for testing purposes i think would be OK. I am thinking
that the problem is when the script runs it is setup with a group of
nobody, setting to 707 would allow that to write the file, if it were
a permission problem causing the issue, using 707 would make anyone
able to write to the folder, but would also tell for sure if the
folder permissions are the cause of the problems the OP is having.
Hans Fredrik Nordhaug
I don't understand how that can make any difference, but I tested with
"wb" and it made no difference - try for yourself:
http://home.no.net/moldevbk/fopen-test/?mode=wb
Hans
Hans Fredrik Nordhaug
The folder is already set to 777 as the URL
http://home.no.net/moldevbk/fopen-test/ tells you. How setting it to
something more restrictive will help beats me. (I did test and it of
course made no difference.)
Are you just suggesting all the standard answers in stead of reading
what I write? Thx for your time anyway.
Hans
Hans Fredrik Nordhaug
> david...@techie.com wrote:
>> On Jul 27, 12:00 pm, Hans Fredrik Nordhaug <han...@gmail.com> wrote:
>>> I'm trying to write to a file in the current directory - no remote
>>> files. The subject says it all - I can add that both the directory
>>> and the file is wordwritable. This happens on a (quite good) free
>>> hoster in Norway which doesn't use safe mode, running PHP 5.1.6 as the
>>> PHP info below shows ...
>>>
>>> Test it at:
>>> http://home.no.net/moldevbk/fopen-test/?mode=a (append - ok)
>>> http://home.no.net/moldevbk/fopen-test/p.php - PHP info
>>> code of test script.
>>>
>>> I have searched the web and usenet, but not found this problem
>>> mentioned before. I do realize that I can work around the problem by
>>> truncating the file first and then appending to the empty file - but
>>> that is ugly as ...
>>>
>>> Regards, Hans
>>>
>>> --
>>> + It's GNU/Linux, not Linux ->http://www.gnu.org/gnu/linux-and-gnu.html
>>> + Support the Free Software Foundation ->http://member.fsf.org/
>>> + Become an Open Directory Project Editor ->http://dmoz.org/
>>
>> make sure the directory is set to allow group writing with permissions
>> set to 707. then it shoudl allow it to work.
>>
>
> 707 is NOT a good one to use. It means anyone can write to the file.
> And if it's not an executable file, you shouldn't have the execute bit on.
>
> 600 is great if the webserver is going to be the only one accessing it;
> Otherwise you should use 660 with the proper group settings.
Come on guys - as the URL http://home.no.net/moldevbk/fopen-test/
shows the execute bit isn't set for the file, only for the directory
(where it's needed). And if you pay even more attention to what I
wrote (and the URL above shows), you'll notice that
1) this is free hoster so I can't change how the groups are setup
2) you have to allow anyone (666) to write to the file because nobody
(the web server user) isn't member of the users group.
Anyway, thx for your time.
Hans
Jerry Stuckle
You should set it to what's appropriate. Seldom is 777 appropriate, and
PHP may disallow access to a file or directory so set up.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Jerry Stuckle
I would NEVER set anything up on a test server different than a
production server.
The purpose of a test server is to find problems BEFORE they occur. And
to do so, you need to emulate the production environment.
Setting different flags does NOT do this.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Jerry Stuckle
0) I wasn't responding to you - I was responding to David.
1) You get what you pay for. Get a decent host.
2) See 1).
You can get good hosts very inexpensively. You want free? All you're
doing is trading a monthly bill for your time.
And quite frankly, you can't buy much of my time for $3-5/mo. Or even
the $25-40/mo. I pay for vps's.
Hans Fredrik Nordhaug
I'm truly sorry - I realized this after posting.
> 1) You get what you pay for. Get a decent host.
This host has worked well for 5 years and is decent.
I'm asking here to see if anyone has seen this type of problem before
because I expect it to be a bug in PHP.
In my view it's very strange that the file is truncated, but can't
be written to ...
Regards,
Hans
Hans Fredrik Nordhaug
But this isn't case here - 777 (or really 707) is a appropriate since
the webserver user is "nobody" which isn't part of the group users.
Hans
Hans Fredrik Nordhaug
> I'm trying to write to a file in the current directory - no remote
> files. The subject says it all - I can add that both the directory
> and the file is wordwritable. This happens on a (quite good) free
> hoster in Norway which doesn't use safe mode, running PHP 5.1.6 as the
> PHP info below shows ...
>
> Test it at:
> http://home.no.net/moldevbk/fopen-test/?mode=w (write - fails)
> http://home.no.net/moldevbk/fopen-test/?mode=a (append - ok)
> http://home.no.net/moldevbk/fopen-test/p.php - PHP info
> http://home.no.net/moldevbk/fopen-test/fopen-test.phps - source code of test script.
>
> I have searched the web and usenet, but not found this problem
> mentioned before. I do realize that I can work around the problem by
> truncating the file first and then appending to the empty file - but
> that is ugly as ...
>
> Regards, Hans
Just some additional information:
If I delete the file I'm trying to write to, fopen with w mode creates
the file (with owner "nobody") and no errors occurs after that.
Apperently PHP is able to write to the file when it's owned by
"nobody" with permission 644, but not when it's owned by the user
"moldevbk" with permission 666. This is something I would expect to
happen if safe mode was on, but it's not. Append mode works in both
situation. The file is also truncated by the write fopen call in both
situation.
What is going?
Hans
PS! I have contacted the hoster - I'll let you know if they have
some explanation/solution to the issue.
frode....@gmail.com
> On 2007-07-27, Hans Fredrik Nordhaug wrote:
>
>
>
> > I'm trying to write to a file in the current directory - no remote
> > files. The subject says it all - I can add that both the directory
> > and the file is wordwritable. This happens on a (quite good) free
> > hoster in Norway which doesn't use safe mode, running PHP 5.1.6 as the
> > PHP info below shows ...
>
> > Test it at:
> >http://home.no.net/moldevbk/fopen-test/?mode=w(write - fails)
> >http://home.no.net/moldevbk/fopen-test/?mode=a(append - ok)
> >http://home.no.net/moldevbk/fopen-test/p.php- PHP info
>
> > I have searched the web and usenet, but not found this problem
> > mentioned before. I do realize that I can work around the problem by
> > truncating the file first and then appending to the empty file - but
> > that is ugly as ...
>
> > Regards, Hans
>
> Just some additional information:
>
> If I delete the file I'm trying to write to, fopen with w mode creates
> the file (with owner "nobody") and no errors occurs after that.
> Apperently PHP is able to write to the file when it's owned by
> "nobody" with permission 644, but not when it's owned by the user
> "moldevbk" with permission 666. This is something I would expect to
> happen if safe mode was on, but it's not. Append mode works in both
> situation. The file is also truncated by the write fopen call in both
> situation.
>
> What is going?
>
> Hans
>
> PS! I have contacted the hoster - I'll let you know if they have
> some explanation/solution to the issue.
I have investigated this, and there is indeed a problem on our part.
The problem was introduced when we upgraded a web server, and is
caused by incompatibilities with some of the file servers. This does
not affect all of our users.
If you want, I can move your account to a different file server. I was
about to do this anyway, but I discovered that you reference absolute
paths in your scripts. I advise you to use relative paths or at least
build the paths from $_ENV['HOME'] or similar.
We will try to solve the problem as soon as possible.
--
Frode Nordahl
Hans Fredrik Nordhaug
Thx for the info - I'm glad it wasn't me (or a bug in PHP).
> If you want, I can move your account to a different file server. I was
> about to do this anyway, but I discovered that you reference absolute
> paths in your scripts. I advise you to use relative paths or at least
> build the paths from $_ENV['HOME'] or similar.
Feel free to move my account - just send me an e-mail when it's done.
(If the issue is fixed this week without moving, I can wait.)
Hans
PS! I would of course prefer to use $_ENV['HOME'], but $_ENV doesn't
contain HOME because the current user is "nobody" ... The absolute
paths is set in one single file so updating is no problem.
Jerry Stuckle
Use $_SERVER['DOCUMENT_ROOT'] instead. It contains the root directory
of your virtual host. No changes required when you move your site.
Hans Fredrik Nordhaug
> Hans Fredrik Nordhaug wrote:
>> On 2007-07-31, frode....@gmail.com wrote:
>>> On Jul 28, 7:58 am, Hans Fredrik Nordhaug <han...@gmail.com> wrote:
>>>> PS! I have contacted the hoster - I'll let you know if they have
>>>> some explanation/solution to the issue.
>>> I have investigated this, and there is indeed a problem on our part.
>>> The problem was introduced when we upgraded a web server, and is
>>> caused by incompatibilities with some of the file servers. This does
>>> not affect all of our users.
>>
>> Thx for the info - I'm glad it wasn't me (or a bug in PHP).
>>
>>> If you want, I can move your account to a different file server. I was
>>> about to do this anyway, but I discovered that you reference absolute
>>> paths in your scripts. I advise you to use relative paths or at least
>>> build the paths from $_ENV['HOME'] or similar.
>>
>> Feel free to move my account - just send me an e-mail when it's done.
>> (If the issue is fixed this week without moving, I can wait.)
>>
>> Hans
>>
>> PS! I would of course prefer to use $_ENV['HOME'], but $_ENV doesn't
>> contain HOME because the current user is "nobody" ... The absolute
>> paths is set in one single file so updating is no problem.
>
> Use $_SERVER['DOCUMENT_ROOT'] instead. It contains the root directory
> of your virtual host. No changes required when you move your site.
Or just dirname(__FILE__). It is a non-issue, but thx for caring.
Jerry Stuckle
dirname(__FILE__) gives the path to the current file - which may or may
not be in the root directory of the server, and will change if you move
the file. $_SERVER['DOCUMENT_ROOT'] is always the root directory of the
server and will not change if you move the file.
Hans Fredrik Nordhaug
> Hans Fredrik Nordhaug wrote:
[cut]
>>> Use $_SERVER['DOCUMENT_ROOT'] instead. It contains the root directory
>>> of your virtual host. No changes required when you move your site.
>>
>> Or just dirname(__FILE__). It is a non-issue, but thx for caring.
>>
>> Hans
>>
>
> dirname(__FILE__) gives the path to the current file - which may or may
> not be in the root directory of the server, and will change if you move
> the file. $_SERVER['DOCUMENT_ROOT'] is always the root directory of the
> server and will not change if you move the file.
Please let it go. I do actually know (very well) what I'm doing -
dirname(__FILE__) or really dirname(dirname(__FILE__)) is exactly what
I want, so I freely can move/rename the directories containing the
file. But thx again for caring.