On 1/4/2011 10:19 PM, justaguy wrote:
> On Jan 3, 7:37 pm, Jerry Stuckle<jstuck...@attglobal.net> wrote:
>> On 1/3/2011 6:11 PM, justaguy wrote:
>>
>>
>>
>>> On Jan 3, 6:53 am, Jerry Stuckle<jstuck...@attglobal.net> wrote:
>>>> On 1/2/2011 11:29 PM, justaguy wrote:
>>
>>>> >>> Jerry,
>>
>>>> >>> The code isn't working, so, of course it's not in production. I'm
>>>> >>> using an ISP's server, don't have a lot of control...
>>>> >>> yes, you're right, I was lazy in error detection/tracking for this
>>>> >>> piece of code, thought it should be fairly straight-forward.
>>
>>>> >>> Thanks.
>>
>>>> >>> Don
>>
>>>> >> Another point - get your own development machine going. It will make
>>>> >> your life a lot easier. Even if it's not the same OS and won't catch
>>>> >> every error (i.e. you wouldn't see this error on Windows), it will help
>>>> >> you many other ways.
>>
>>>> >> And depending on the ISP's setup, ini_set() and/or your .htaccess file
>>>> >> can change a number of PHP settings for a single script, every script on
>>>> >> your site, or many steps in between.
>>
>>>> > Too bad, an open source webserver, Caucho Resin on my Windows 7 box
>>>> > fails to support php. The same code produced a blank page with
>>>> > nothing.
>>
>>>> Why don't you just install Apache - it's open source, free and supports
>>>> PHP just fine. It also happens to be the most used web server in the
>>>> world.
>>
>>>> And BTW - I didn't say the code was "in production". I said it was "on
>>>> a production machine". Two entirely different things.
>>
>>> Hi all, problem resolved with the same (my 'original' code). My ISP
>>> first adversely changed file attributes of another text file,
>>> Terrible! Which failed my software download routine, anyway, after
>>> calling them up and instructing them to set it to rw rw rw, all's well
>>> now.
>>
>>> But let me ask Jerry and all, how do we ensure the "target file" to
>>> support concurrent users, if it's opened by user A, we need to lock it
>>> or something... how do we do it with php?
>>
>>> Many thanks.
>>
>>> Don
>>
>> It should NOT be world writable, which is one security exposure.
>> Another is that anyone can download the file at any time, because it's
>> in your web site's root directory. Both are bad. At the very least you
>> should protect access through .htaccess, and better is to have it
>> outside your web site's root.
>>
>> You can single thread access on some OS's - see flock() in the PHP
>> documentation. But better is to use a database, which will solve all
>> these problems.
>>
>
>
> "
> It should NOT be world writable,
> "
> world writable means to let Internet users to write to it, so, the
> global w attribute is removed, how could an anonymous user
> write to it?
>
No, world writable means anyone else on that server can write to it -
including other users. You may have 150 web sites on a shared server,
with each web site having its own users. Any of them can overwrite your
file.
>
> "and better is to have it outside your web site's root."
> Yes, for now it's for dev purpose, so, I didn't care.
>
Doesn't matter. If you start with good habits, you have fewer problems
later.
> "
> You can single thread access on some OS's - see flock() in the PHP
> documentation.
> "
> sample code? Since I'm not a php coder and don't intend to become
> one, at least not now... could you save me some time?
>
At my normal consulting rates, I can. This newsgroup is for users
helping users, not free consulting.
> "
> But better is to use a database, which will solve all these problems.
> "
> No, not practical, this is a temp task (a poll).
>
> Thanks.
>
Still better to use a database - and completely practical.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
Calendar
Search
Help
Members
Register
Login
Home
]