Re: [PHP] Re: Upload File (binary files?)

[Rory Browne]

How is it not suited?

I stopped using mySQL to store images because of
browser refresh problems, but other than that --
I didn't find any major problems with using it.

Plus, moving images from one system to another
was much easier because you just moved the dB and
you don't have to worry about the file system and
breaking links.



Bullshit. there are multiple tools for copying files from host to host,
including ftp, scp, sftp, rsync, nfs, etc. Planning ahead, is  a better way
to avoid breaking links than using MySQL to store your images.


In addition, if you are using multiple hosts, who

require the same images, then using mySQL is far
superior than trying to keep all the images in
different file systems synchronized.


Not it's not. If you have a single mysql server then this situation can be
replicated by having a single image server. If you have a clustered mysql
system, then this can be replicated using something like rsync



Furthermore, according to Paul DuBois (author of

MySQL Cookbook, great book btw) who says "If you
store images on the file system, directory
look-up my become slow" in his comparing file
system to mySQL for image storage.


I notice you've misspelt the most important word there. He says the lookup
_MAY_ become slow. This behavour is dependent on the filesystem you are
using. You will encounter this problem with ext3 if you have too many files
in the same dir. You're less likely to encounter it with reiser. This comes
down to the competance of the administrator. An incompetantly setup mysql
table ( without indexes ) would have the same problem.


Additionally, transactional behavior is more

difficult with a file system than it is with
mySQL.

Granted, if you use mySQL for storing images,
then you bloat the tables and approach your
system limits faster than using a file system.
But for a limited amount of images, there isn't
any real problems.



For a small enough site you can encode all your images inside a bigger image
using stenography. Bad solutions generally work for small enough sites.
Failing to plan for the growth of your site is however a bad idea.

And granted, pulling images from mySQL to be used

in web sites are slightly slower and present
refresh differences between some browsers, but
that's certainly not a reason to say that mySQL
is categorically not suited for the storage of
binary files -- like with everything else, there
are trade-offs. Do you not see that?



We're not talking about generic binary files. We're talking about images
images that people upload. Using blobs to store small (order of kbs) of
transient data is fine. I just don't want to end up maintaining systems that
store images in the sql db.

---


At 1:53 AM +1000 5/11/06, Peter Hoskin wrote:
>So, if ASCII and Binary are both codesets... which does SQL use to store
>its data?

Is ASCII stored differently than binary on a hard drive?

From my limited experience in using a hex editor,
the data all looks the same to me. If it wasn't
for my hex editor, I would be looking at 1's and
0's, right?

After all, isn't an image in a file system stored
on a hard drive the exact same fashion as an
image stored on a hard drive via mySQL?

The only difference I can see is in overhead --
but then again, I may be a Moron or an Idiot like
Rory Browne suggests.


I notice you took the first two words of my post and ignored the rest - I
also allowed the option of newbie. my biggest problem with it is the
administration difficulties this presents.



Perhaps someone might enlighten me as to why

mySQL is not suited to store images -- and prove
it.


At work our MySQL DB recently hit a 4G limit in the table storage Engine.
That wouldn't have happened if a competant programmer had set it up to put
the images in the FS.


And for goodness sake NO, Google is NOT always

right -- it's only a collection of everyone's
view. When did Google replace valid research? I
can see tomorrow's mother's saying to their
children "If Google jumped off a bridge, would
you do it?"

Let's get real about what Google can offer.
Specificity is inversely proportional to the
number of people voicing an opinion. I would
guess that even Morons and Idiots know that.


Okay - you're right, and everyone who put up sites on this topic, that got
indexed by google is wrong.

tedd


Typical disclaimers apply -- I did not mean to
offend anyone nor to imply that anyone is an
Idiot or a Moron. Your mileage may vary. No
warranties expressed or implied. This is not a
solicitation for an investment opportunity.
Consult you doctor before applying.  No hable
inglés.

--


http://sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File (binary files?)

[Rory Browne]

How is it not suited?

I stopped using mySQL to store images because of
browser refresh problems, but other than that --
I didn't find any major problems with using it.

Plus, moving images from one system to another
was much easier because you just moved the dB and
you don't have to worry about the file system and
breaking links.



Bullshit. there are multiple tools for copying files from host to host,
including ftp, scp, sftp, rsync, nfs, etc. Planning ahead, is  a better way
to avoid breaking links than using MySQL to store your images.


In addition, if you are using multiple hosts, who

require the same images, then using mySQL is far
superior than trying to keep all the images in
different file systems synchronized.


Not it's not. If you have a single mysql server then this situation can be
replicated by having a single image server. If you have a clustered mysql
system, then this can be replicated using something like rsync



Furthermore, according to Paul DuBois (author of

MySQL Cookbook, great book btw) who says "If you
store images on the file system, directory
look-up my become slow" in his comparing file
system to mySQL for image storage.


I notice you've misspelt the most important word there. He says the lookup
_MAY_ become slow. This behavour is dependent on the filesystem you are
using. You will encounter this problem with ext3 if you have too many files
in the same dir. You're less likely to encounter it with reiser. This comes
down to the competance of the administrator. An incompetantly setup mysql
table ( without indexes ) would have the same problem.


Additionally, transactional behavior is more

difficult with a file system than it is with
mySQL.

Granted, if you use mySQL for storing images,
then you bloat the tables and approach your
system limits faster than using a file system.
But for a limited amount of images, there isn't
any real problems.



For a small enough site you can encode all your images inside a bigger image
using stenography. Bad solutions generally work for small enough sites.
Failing to plan for the growth of your site is however a bad idea.

And granted, pulling images from mySQL to be used

in web sites are slightly slower and present
refresh differences between some browsers, but
that's certainly not a reason to say that mySQL
is categorically not suited for the storage of
binary files -- like with everything else, there
are trade-offs. Do you not see that?



We're not talking about generic binary files. We're talking about images
images that people upload. Using blobs to store small (order of kbs) of
transient data is fine. I just don't want to end up maintaining systems that
store images in the sql db.

---


At 1:53 AM +1000 5/11/06, Peter Hoskin wrote:
>So, if ASCII and Binary are both codesets... which does SQL use to store
>its data?

Is ASCII stored differently than binary on a hard drive?

From my limited experience in using a hex editor,
the data all looks the same to me. If it wasn't
for my hex editor, I would be looking at 1's and
0's, right?

After all, isn't an image in a file system stored
on a hard drive the exact same fashion as an
image stored on a hard drive via mySQL?

The only difference I can see is in overhead --
but then again, I may be a Moron or an Idiot like
Rory Browne suggests.

Perhaps someone might enlighten me as to why
mySQL is not suited to store images -- and prove
it.

And for goodness sake NO, Google is NOT always
right -- it's only a collection of everyone's
view. When did Google replace valid research? I
can see tomorrow's mother's saying to their
children "If Google jumped off a bridge, would
you do it?"

Let's get real about what Google can offer.
Specificity is inversely proportional to the
number of people voicing an opinion. I would
guess that even Morons and Idiots know that.

tedd

Typical disclaimers apply -- I did not mean to
offend anyone nor to imply that anyone is an
Idiot or a Moron. Your mileage may vary. No
warranties expressed or implied. This is not a
solicitation for an investment opportunity.
Consult you doctor before applying.  No hable
inglés.

--


http://sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File (binary files?)

[tedd]

At 11:07 PM +0200 5/11/06, Jochem Maas wrote:

I think you make interesting points Tedd, it's given me stuff to 
think about anyway.
leveraging a Db for image storage can have advantages but 
implementing it correctly
takes a stack more knowledge and more work to do it correctly, 
therefore the recommendation
for those starting out in php should, I feel, remain 'use the 
filesystem' - if only
because understanding and using the filesystem properly is one of 
the foundations

of the craft. no?


For beginners, I would have to agree because, as you said, they 
already have already been exposed to the concept of the "file system".


But, at some point (and I forgot to mention this in my previous post) 
all programmers start thinking in collections of data and a dB 
becomes a well suited solution (record holder and organizer) for 
that. As such, all data connected to a record, including images, are 
"better" suited if organized and saved in one place.


With regard to problems in display, speed, storage, and such -- those 
are just the temporary growing pains of the industry and will pass. 
Remember Gopher?  The Internet has come a long way since then. I 
suspect that in five-ten years, people will arguing "You still use 
the file system for storing those?"


with regard to the refresh issues I believe this can be dealt with 
by outputting

correct last-modified headers with the image data (which can also be
stored in the DB ;-)


Interesting -- but, I had problems with different browsers -- some 
worked and some didn't. So, I resorted to the "file system" for the 
storage for both thumbnail and normal size images. I was spending too 
much time trying to fix it for all main browsers, so I took the 
easy-way out. It works (I think) see:


http://ancientstones.com

At least I put it up for review in css and through BrowserCam.

with regard to increasing speed: what I often end up doing, mostly 
because I allow

dynamic resizing of images (i.e. the thumbnail and the 'large' image come
from a single stored source) is to use a memory based cache where previously
outputted images are stored for as long as possible (i.e. until the 
source changes

or the server is restarted or the cache is full or whatever).


I did the same thing including merging a copyright on the image. I 
believe that saving all related data in a dB is really the "right" 
way to go. From there, you can do anything you want with the data.


tedd
--

http://sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File (binary files?)

[Jochem Maas]

tedd wrote:

At 1:02 AM +1000 5/11/06, Peter Hoskin wrote:


Despite common belief, SQL is not suited to the storage of binary files.
SQL is based on ASCII.
Store your files on the filesystem, not SQL.



How is it not suited?

I stopped using mySQL to store images because of browser refresh 
problems, but other than that -- I didn't find any major problems with 
using it.


Plus, moving images from one system to another was much easier because 
you just moved the dB and you don't have to worry about the file system 
and breaking links.


In addition, if you are using multiple hosts, who require the same 
images, then using mySQL is far superior than trying to keep all the 
images in different file systems synchronized.


Furthermore, according to Paul DuBois (author of MySQL Cookbook, great 
book btw) who says "If you store images on the file system, directory 
look-up my become slow" in his comparing file system to mySQL for image 
storage.


Additionally, transactional behavior is more difficult with a file 
system than it is with mySQL.


Granted, if you use mySQL for storing images, then you bloat the tables 
and approach your system limits faster than using a file system. But for 
a limited amount of images, there isn't any real problems.


And granted, pulling images from mySQL to be used in web sites are 
slightly slower and present refresh differences between some browsers, 
but that's certainly not a reason to say that mySQL is categorically not 
suited for the storage of binary files -- like with everything else, 
there are trade-offs. Do you not see that?




I think you make interesting points Tedd, it's given me stuff to think about 
anyway.
leveraging a Db for image storage can have advantages but implementing it 
correctly
takes a stack more knowledge and more work to do it correctly, therefore the 
recommendation
for those starting out in php should, I feel, remain 'use the filesystem' - if 
only
because understanding and using the filesystem properly is one of the 
foundations
of the craft. no?

with regard to the refresh issues I believe this can be dealt with by outputting
correct last-modified headers with the image data (which can also be
stored in the DB ;-)

with regard to increasing speed: what I often end up doing, mostly because I 
allow
dynamic resizing of images (i.e. the thumbnail and the 'large' image come
from a single stored source) is to use a memory based cache where previously
outputted images are stored for as long as possible (i.e. until the source 
changes
or the server is restarted or the cache is full or whatever).

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File (binary files?)

[tedd]

At 1:02 AM +1000 5/11/06, Peter Hoskin wrote:

Despite common belief, SQL is not suited to the storage of binary files.
SQL is based on ASCII.
Store your files on the filesystem, not SQL.


How is it not suited?

I stopped using mySQL to store images because of 
browser refresh problems, but other than that -- 
I didn't find any major problems with using it.


Plus, moving images from one system to another 
was much easier because you just moved the dB and 
you don't have to worry about the file system and 
breaking links.


In addition, if you are using multiple hosts, who 
require the same images, then using mySQL is far 
superior than trying to keep all the images in 
different file systems synchronized.


Furthermore, according to Paul DuBois (author of 
MySQL Cookbook, great book btw) who says "If you 
store images on the file system, directory 
look-up my become slow" in his comparing file 
system to mySQL for image storage.


Additionally, transactional behavior is more 
difficult with a file system than it is with 
mySQL.


Granted, if you use mySQL for storing images, 
then you bloat the tables and approach your 
system limits faster than using a file system. 
But for a limited amount of images, there isn't 
any real problems.


And granted, pulling images from mySQL to be used 
in web sites are slightly slower and present 
refresh differences between some browsers, but 
that's certainly not a reason to say that mySQL 
is categorically not suited for the storage of 
binary files -- like with everything else, there 
are trade-offs. Do you not see that?


---

At 1:53 AM +1000 5/11/06, Peter Hoskin wrote:

So, if ASCII and Binary are both codesets... which does SQL use to store
its data?


Is ASCII stored differently than binary on a hard drive?

From my limited experience in using a hex editor, 
the data all looks the same to me. If it wasn't 
for my hex editor, I would be looking at 1's and 
0's, right?


After all, isn't an image in a file system stored 
on a hard drive the exact same fashion as an 
image stored on a hard drive via mySQL?


The only difference I can see is in overhead -- 
but then again, I may be a Moron or an Idiot like 
Rory Browne suggests.


Perhaps someone might enlighten me as to why 
mySQL is not suited to store images -- and prove 
it.


And for goodness sake NO, Google is NOT always 
right -- it's only a collection of everyone's 
view. When did Google replace valid research? I 
can see tomorrow's mother's saying to their 
children "If Google jumped off a bridge, would 
you do it?"


Let's get real about what Google can offer. 
Specificity is inversely proportional to the 
number of people voicing an opinion. I would 
guess that even Morons and Idiots know that.


tedd

Typical disclaimers apply -- I did not mean to 
offend anyone nor to imply that anyone is an 
Idiot or a Moron. Your mileage may vary. No 
warranties expressed or implied. This is not a 
solicitation for an investment opportunity. 
Consult you doctor before applying.  No hable 
inglés.


--

http://sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Jochem Maas]

Jochem Maas wrote:

thank you Edward.



...



there is a funny little story about where the name BLOB came from:
http://www.cvalde.net/misc/blob_true_history.htm


just to note that BLOBs where invented by the guy that designed Interbase
which just happens to be the ancestor of the coolest DBMS you can connect
to php with ;-) namely firebird. of course I'm biased - a friend of mine
wrote the php ibase/fbird extension :-)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Jochem Maas]

thank you Edward.

Edward Vermillion wrote:
>
> On May 10, 2006, at 10:53 AM, Peter Hoskin wrote:
>
>>
>> GOOGLE DO NOT ARGUE
>
>
> o_O?

yeah! I did figure it really was about time they changed their
'Do No Evil' slogan given their escapades in china

funnily enough I watched a documentary the other day about the
potential for information/propaganda abuse given the way major
search engines operator and dominate.

'Google: do not argue' is pretty fitting all in all. lol.

>
>>
>> So, if ASCII and Binary are both codesets... which does SQL use to  store
>> its data?
>>
>
> ASCII is a codeset, utf* is a codeset binary is a, um... , binary
> data.
>
> varchar, etc => ASCII/utf*/whatever => stored as text
> int, etc => integer => stored as integer or long or whatever
> BLOB => Binary Large OBject => stored as binary data

there is a funny little story about where the name BLOB came from:
http://www.cvalde.net/misc/blob_true_history.htm

>
> While you're right that it's better performance and maintenance wise  to
> use the filesystem to store binary objects, especially very large  ones,
> it's not necessarily 'wrong' to use MySQL.
>
> http://dev.mysql.com/doc/refman/5.1/en/index.html
>
> Ed
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Rory Browne]

There are names for people who use the blob field of a MySQL db to store
images.
Moron, and Idiot are just two examples, but if other circumstances exist,
you can say newbie as well. As a newbie I thought myself that storing images
in a DB would be a nice clean solution. Voices of experience said otherwise.
Over the years as I grew more experienced I began to understand myself, why
putting images into a MySQL Db is a Bad Thing[tm].

Use blobs to store small amounts of transient data. Use the FS to store
something as large and semi-static as images.

Sorry if this seems rough / harsh, but if it causes a person to think twice
before using MySQL as a file storage solution, then it's justified.

There are a few less polite names for people who develop software like this
that I have to maintain later.



Are you going to write queries that involve the data *IN* the file as
part of the search, sort, or filtering?

PHP has the facilities built-in to perform this search/sort/filter - while
their use isn't always the cleanest solution, anything is better than
putting files in a db.

If you can't find the features you require, then feel free to use external
tools - anything to avoid db file storage.

Re: [PHP] Re: Upload File

[Richard Lynch]

On Wed, May 10, 2006 9:52 am, Renzo Clavijo wrote:
> I'm gonna be more precise:
>
> I wrote a form with fields , then i need to

Should be  know how
> to upload the files to the MySQL server (postgreSQL wold be
> appreciated). It
> implies: Which field(s) must have the table where I'll save the
> image?. Is
> there an example code to upload the file(s)?

Are you going to write queries that involve the data *IN* the file as
part of the search, sort, or filtering?

If not, then just toss the files in the file-system and store the path
to the file in the db.  Much cleaner/easier.

If you MUST store the data in the db, the size of the data determines
the type of the field:
varchar, text, blob, bigblob, humungousblob

And, of course, this all depends on WHICH database you are using...
Some call it "memo" some call it "blob" some call it something else.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Edward Vermillion]

On May 10, 2006, at 10:53 AM, Peter Hoskin wrote:



GOOGLE DO NOT ARGUE


o_O?



So, if ASCII and Binary are both codesets... which does SQL use to  
store

its data?



ASCII is a codeset, utf* is a codeset binary is a, um... , binary  
data.


varchar, etc => ASCII/utf*/whatever => stored as text
int, etc => integer => stored as integer or long or whatever
BLOB => Binary Large OBject => stored as binary data

While you're right that it's better performance and maintenance wise  
to use the filesystem to store binary objects, especially very large  
ones, it's not necessarily 'wrong' to use MySQL.


http://dev.mysql.com/doc/refman/5.1/en/index.html

Ed

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Peter Hoskin]

Jochem Maas wrote:
> Peter Hoskin wrote:
>> Renzo Clavijo wrote:
>>
>>> hi all..
>>>
>>> I'm gonna be more precise:
>>>
>>> I wrote a form with fields , then i need to
>>> know how
>>> to upload the files to the MySQL server (postgreSQL wold be
>>> appreciated). It
>>> implies: Which field(s) must have the table where I'll save the
>>> image?. Is
>>> there an example code to upload the file(s)?
>>
>> Despite common belief, SQL is not suited to the storage of binary files.
>> SQL is based on ASCII.
>
> wtf? ASCII is a codeset, SQL is a theoretical language specification.
> it's like saying 'software is based on computers.' - completely
> besides the point.
GOOGLE DO NOT ARGUE

So, if ASCII and Binary are both codesets... which does SQL use to store
its data?

Regards,
Peter Hoskin

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Jochem Maas]

Peter Hoskin wrote:

Renzo Clavijo wrote:


hi all..

I'm gonna be more precise:

I wrote a form with fields , then i need to
know how
to upload the files to the MySQL server (postgreSQL wold be
appreciated). It
implies: Which field(s) must have the table where I'll save the
image?. Is
there an example code to upload the file(s)?


Despite common belief, SQL is not suited to the storage of binary files.
SQL is based on ASCII.


wtf? ASCII is a codeset, SQL is a theoretical language specification.
it's like saying 'software is based on computers.' - completely besides the 
point.

from a performance angle I would never suggest putting image/binary data
into a DB. but to say it's not technically suitable is silly - a 'BLOB' field
is designed specifically for the storage of binary data.


Store your files on the filesystem, not SQL.


in practice that is indeed a sound recommendation - what many people do do is
use the DB to store information about the files that have been uploaded
(original size, original name, location on disk, etc) - which can be very
handy indeed.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Barry]

Peter Hoskin schrieb:

But mysql can be quite a good spool though.

That way you don't have to code one for yourself.


That does not mean that there are not SIGNIFICANT ADVANTAGES to coding
something to use the filesystem - such as seek speed. When dealing with
large datasets of binary, filesystems are much quicker at seeking.


I was talking about a spool not a filesystem.
Do you actually read my comments?


As I said, images are binary and sql is ascii - does it sound suited to you?


No Problem with that.



Google, don't argue - many will agree with me.



No need to cry. ;)


Best wishes
Barry
--
Smileys rule (cX.x)C --o(^_^o)
Dance for me! ^(^_^)o (o^_^)o o(^_^)^ o(^_^o)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Peter Hoskin]

> But mysql can be quite a good spool though.
>
> That way you don't have to code one for yourself.
>
That does not mean that there are not SIGNIFICANT ADVANTAGES to coding
something to use the filesystem - such as seek speed. When dealing with
large datasets of binary, filesystems are much quicker at seeking.

As I said, images are binary and sql is ascii - does it sound suited to you?

Google, don't argue - many will agree with me.

Regards,
Peter Hoskin

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Barry]

Peter Hoskin schrieb:

Renzo Clavijo wrote:

hi all..

I'm gonna be more precise:

I wrote a form with fields , then i need to
know how
to upload the files to the MySQL server (postgreSQL wold be
appreciated). It
implies: Which field(s) must have the table where I'll save the
image?. Is
there an example code to upload the file(s)?

Despite common belief, SQL is not suited to the storage of binary files.
SQL is based on ASCII.
Store your files on the filesystem, not SQL.


But mysql can be quite a good spool though.

That way you don't have to code one for yourself.

--
Smileys rule (cX.x)C --o(^_^o)
Dance for me! ^(^_^)o (o^_^)o o(^_^)^ o(^_^o)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload File

[Peter Hoskin]

Renzo Clavijo wrote:
> hi all..
>
> I'm gonna be more precise:
>
> I wrote a form with fields , then i need to
> know how
> to upload the files to the MySQL server (postgreSQL wold be
> appreciated). It
> implies: Which field(s) must have the table where I'll save the
> image?. Is
> there an example code to upload the file(s)?
Despite common belief, SQL is not suited to the storage of binary files.
SQL is based on ASCII.
Store your files on the filesystem, not SQL.
>
> Thanks a lot.
>
> Best Regards
>
> RENZO CLAVIJO
>

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: upload file - clients path to file?

[Angelo Zanetti]

Angelo Zanetti
Z Logic
www.zlogic.co.za
[c] +27 72 441 3355
[t] +27 21 469 1052



Jasper Bryant-Greene wrote:

> [EMAIL PROTECTED] wrote:
>
>> Well basically i need it for an "add products" page and if the users
>> doesnt fill
>> in all the fields correctly I display some error message as well as
>> populate the
>> textfields and dropdown lists with the values they previously
>> entered, so if
>> they entered/selected the file I want to display it again so they
>> don't have to
>> upload the file again. I know that I could do it without the user
>> knowing
>> (backed) but then they might think they have to select the file again
>> because
>> the upload field will be blank.
>
>
> Please don't top-post. You can *NEVER* set an initial value for a file
> upload field. This would be a HUGE security risk. Imagine (on a Linux
> system):
>
> 
>
> You need to alter your design so that this is unnecessary, for example
> as suggested by someone else -- don't display the upload box and
> display a message saying it is already uploaded, maybe with a link to
> re-upload.
>
>

YEAh thanks I thought it wasn't possible, I'll look at different options
in terms of design and user interaction.
thanks guys!
ciao

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: upload file - clients path to file?

[Jasper Bryant-Greene]

[EMAIL PROTECTED] wrote:

Well basically i need it for an "add products" page and if the users doesnt fill
in all the fields correctly I display some error message as well as populate the
textfields and dropdown lists with the values they previously entered, so if
they entered/selected the file I want to display it again so they don't have to
upload the file again. I know that I could do it without the user knowing
(backed) but then they might think they have to select the file again because
the upload field will be blank.


Please don't top-post. You can *NEVER* set an initial value for a file 
upload field. This would be a HUGE security risk. Imagine (on a Linux 
system):




You need to alter your design so that this is unnecessary, for example 
as suggested by someone else -- don't display the upload box and display 
a message saying it is already uploaded, maybe with a link to re-upload.


Jasper

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: upload file - clients path to file?

[Torgny Bjers]

IMHO this is just a design issue, why not just hide the upload field,
display a message that they need not re-upload, and just add a hidden
field with the name of the uploaded file and once they've corrected
their fields, they re-post, and viola, you've got your file still.

[EMAIL PROTECTED] wrote:

>Thanks for the replies.
>
>Well basically i need it for an "add products" page and if the users doesnt 
>fill
>in all the fields correctly I display some error message as well as populate 
>the
>textfields and dropdown lists with the values they previously entered, so if
>they entered/selected the file I want to display it again so they don't have to
>upload the file again. I know that I could do it without the user knowing
>(backed) but then they might think they have to select the file again because
>the upload field will be blank.
>

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: upload file - clients path to file?

[Mark Rees]

<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thanks for the replies.
>
> Well basically i need it for an "add products" page and if the users
doesnt fill
> in all the fields correctly I display some error message as well as
populate the
> textfields and dropdown lists with the values they previously entered, so
if
> they entered/selected the file I want to display it again so they don't
have to
> upload the file again. I know that I could do it without the user knowing
> (backed) but then they might think they have to select the file again
because
> the upload field will be blank.
>


If that's the problem, you might find it easier to solve by going for two
separate forms - one to enter all the details, and the second just to upload
the file.


>
> Quoting Mark Rees <[EMAIL PROTECTED]>:
>
> > > Hi all.
> > >
> > > I havent found an answer after looking at the manual. I'm trying to
find
> > > out if it possible to find the path of the file on the clients pc once
> > > a  form has been submitted with the file upload form.
> >
> >
> > No, this would be a security risk. If  all your users are on an
intranet,
> > you may be able to implement some kind of client-side scripting to
discover
> > the location, then post it as part of the form. Even this will probably
> > involve amending local security settings on each machine.
> >
> >
> > > I know its possible to get the file name but I need the whole path.
> >
> >
> > What do you need it for? Perhaps there is another way to solve this
problem?
> >
> >
> > > is this possible?
> > > thanks in advance.
> > >
> > > --
> > >
> > > Angelo Zanetti
> > >
> > >
> > >
> > >
> > > 
> > > This message was sent using IMP, the Internet Messaging Program.
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: upload file - clients path to file?

[angelo]

Thanks for the replies.

Well basically i need it for an "add products" page and if the users doesnt fill
in all the fields correctly I display some error message as well as populate the
textfields and dropdown lists with the values they previously entered, so if
they entered/selected the file I want to display it again so they don't have to
upload the file again. I know that I could do it without the user knowing
(backed) but then they might think they have to select the file again because
the upload field will be blank.


Quoting Mark Rees <[EMAIL PROTECTED]>:

> > Hi all.
> >
> > I havent found an answer after looking at the manual. I'm trying to find
> > out if it possible to find the path of the file on the clients pc once
> > a  form has been submitted with the file upload form.
> 
> 
> No, this would be a security risk. If  all your users are on an intranet,
> you may be able to implement some kind of client-side scripting to discover
> the location, then post it as part of the form. Even this will probably
> involve amending local security settings on each machine.
> 
> 
> > I know its possible to get the file name but I need the whole path.
> 
> 
> What do you need it for? Perhaps there is another way to solve this problem?
> 
> 
> > is this possible?
> > thanks in advance.
> >
> > --
> >
> > Angelo Zanetti
> >
> >
> >
> >
> > 
> > This message was sent using IMP, the Internet Messaging Program.
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 





This message was sent using IMP, the Internet Messaging Program.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload file field not working as a form element

[Lowell Allen]

>> The uploaded file name will be $HTTP_POST_FILES["filename"]["name"] -- use
>> that rather than $_POST["filename"].
> 
> I'm sorry I don't understand. What is the extra ["name"] for? When I use
> this in the insert into the value that is inserted into the database is
> Array, as opposed to the actual filename.

The $HTTP_POST_FILES array works for me. Maybe you need to try the $_FILES
array instead. Take a look at the info in the manual:
.

--
Lowell Allen
 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload file field not working as a form element

[Jason Wong]

On Sunday 21 March 2004 22:53, Vernon wrote:
> > The uploaded file name will be $HTTP_POST_FILES["filename"]["name"] --
> > use that rather than $_POST["filename"].
>
> I'm sorry I don't understand. What is the extra ["name"] for? When I use
> this in the insert into the value that is inserted into the database is
> Array, as opposed to the actual filename.

manual > Handling file uploads

-- 
Jason Wong -> Gremlins Associates -> www.gremlins.biz
Open Source Software Systems Integrators
* Web Design & Hosting * Internet & Intranet Applications Development *
--
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
--
/*
SEMPER UBI SUB UBI
*/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload file field not working as a form element

[Vernon]

> The uploaded file name will be $HTTP_POST_FILES["filename"]["name"] -- use
> that rather than $_POST["filename"].

I'm sorry I don't understand. What is the extra ["name"] for? When I use
this in the insert into the value that is inserted into the database is
Array, as opposed to the actual filename.

Thanks
 -V


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Upload file field not working as a form element

[Lowell Allen]

> All I am trying to do is insert the file name, not the file. The file is
> being uploaded to the server in a specific location. All I need is the
> filename inserted into the database. I've gotten the upload part to work and
> everything I just can't get the file name inserted for God knows what
> reason. I removed the upload code and am simply trying to insert the
> filename and userid into the database. The userid goes in but I cannot get
> the file name inserted.
> 
> Here is the form:
> enctype="multipart/form-data" name="form1">
>   
>value="">
>disabled>
>   
> 

The uploaded file name will be $HTTP_POST_FILES["filename"]["name"] -- use
that rather than $_POST["filename"].

HTH

--
Lowell Allen

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php