I have noted that when i upload pictures from my new camera, Canon PowerShot SX150 IS, the exif information don't inserted even on pictures with a resolution of    1600 x 1200 (Below the size limit of LG, where the site resize the pictures).
With the first 1600 x 1200 pixels pictures from my camera, the exif information did inserted, but now its don't.
This looks to me like a site problem.
Why this is happening?

dor123, e-mail one of the original files from your camera to the L-G administrator e-mail address and I'll take a look.

I uploaded today 5 pictures, and it seems that the Exif data was inserted now, so probably this was a site problem, that erased the Exif data of the pictures, since my previous 1600 x 1200 pictures still haven't the Exif data appears.

Update: I uploaded yesterday, another 5 pictures of 1600 x 1200 resolution, and now it seems that 2 of my pictures have their Exif insered while 3 of my picture didn't.

I figured out what has been going on.  You've been uploading files using the file names created by your camera.  For example, a couple of years ago, you uploaded a file named IMG_0127.jpg.  Now you have a new camera and the sequence numbers have started over.  Just the other day you uploaded a similarly named file, IMG_0227.JPG.  Normally, if Coppermine detects a file name conflict, it will automatically rename the new file.  However, notice that in this instance the case of the file extension was different (".JPG" instead of ".jpg").  Our server has a case sensitive filesystem, and therefore no conflict occurred, and CPG did not rename the new file.  Now here is the issue.  Although the file system is case insensitive, the filename column in CPG's EXIF database table is case sensitive.  When you uploaded the new file, CPG found a match in the EXIF table already, and did not insert info for the new file.  The reason you see no EXIF data is that the old file didn't have any (it got lost when it was resized).  Had the old file contained EXIF data, then you would have seen EXIF info for the new file, but it would have been inaccurate.  My solution was to simply make the filename column in the database case sensitive.  Now the correct EXIF data should display even if another file exists with the same name but different case.

When i will upload new pictures, i will see if this is works. Usually there is no meaning to the difference between the case of the letters of the file extension, so jpg should be the same as JPG.
It is very hard to me to change the filename of every picture that i upload to my computer, every time i photographing pictures.
Thanks.
Update: I readed the email that you sent me. Thanks.

The term "file extension" (so the meaning of the last few letters behind the dot in the filename) used to distinguish between different file types and formats does exist only in Windows. For this purpose they are not case sensitive.

But in other operating systems this is simply part of the filename without any special meaning, while the file type is distinguished by other means (executable code vs data files have the file attribute bit, the format is distinguished by the header inside the file) and rigorously speaking "File.jpg" may well be an executable code, while "File.exe" may be a JPEG picture (however the Win "standard" in generating of the "suffix" on data files is followed for the reason of compatibility with Windows systems; executables usually do not use any suffix, as they do not need the compatibility, they won't work in Windows anyway).
So for the file system it does not matter, what they are (and if they are there at all). And if the file system is case sensitive in the file names, the "File.jpg" is another file than the "File.JPG"...

Medved: I bet that Ash can explain this, as he knows on computer software.
There are two common file system in Windows that are used on HDD, USB flash drives and SSD: FAT32 and NTFS. I use NTFS on my HDD and my Sandisk Ultra 8GB USB flash drive. NTFS isn't case sensitive for the file extensions and the filenames, even if it allows to make files with different lettercases without converting them to uppercase letters as FAT32 and the DOS FAT does.

The fact that it was the extension that differed in case was irrelevant.  The same issue would have occurred if the same person uploaded both IMG_0127.jpg and img_0127.jpg, for instance.  The filesystem on the server is capable of storing IMG_0127.jpg, img_0127.jpg, IMG_0127.jpg, and IMG_0127.JPG, etc. all as distinct files in the same directory.  This is true for most Linux/UNIX filesystems.  However, the filename column in our database was not case sensitive, and when Coppermine queried for "IMG_0227.JPG" in the EXIF table, the information for "IMG_0227.jpg" was brought back.  Now that I've made the database column case sensitive, this will no longer be an issue.  This should correct files already on the site because the EXIF database table is simply used as a cache to improve performance.  When no match is found in the database, it goes back to the image file.  So in short, all files that were not displaying EXIF data properly due to this bug should be OK now.  Of course, if a file never contained EXIF data or it was lost due to compression, this change will not fix that. 

A bit more for Dor123 :

Your computer is running Windows, using NTFS or a FAT variant file system

The server that hosts Lighting Gallery is running Linux, probably Apache for server software, probably Mysql for the database, and PHP (the combination of which is called LAMP, how appropriate for a server hosting Lighting Gallery ^_^)



When you upload a file, only the file name and file contents are transferred. The file is then saved on the native file system on the server - typically ext3/4 or reiserfs in Linux servers

NTFS and the FAT variants have by far complex file name rules. There are lots of them :

A=a, B=b etc. Those rules add complexity, while from a computer point of view they dont make any more sense than a=b, c=d, e=f or any other "identities" between different characters

There is filename extension which is determining the file type

And there are lots of forbidden characters like CR, LF, ?, * etc

Those rules dont apply in Linux file systems - so for example a file can be img_0127 and this does not prevent a file Img_0127 in the same folder, since 'I' is not the same as 'i' and the operating system will not confuse the 2 files

You can also have files with various forbidden characters in them like

IMG_
0*27?jpg

(yep this one has an ENTER in its name as well as * and ? and the operating system is capable of dealing with it as long as you use proper escaping when specifying the file name)



We can place the file in the directory on the server. Now we have to save its path and name in the database, so we can look in the database later and go find it on the filesystem

The database has its own limitations on data saved in it. When inputting strings to the database you have to escape them, to prevent then from breaking up and causing trouble, possibly big trouble :

1. At the least, only the 1st part of the string will be saved in the database, causing loss of data - a field will be empty, the picture in question won't be dispalyed etc

2. In some badly written software (and Coppermine Gallery does not appear to be written too well), you can have 2 consequent insert's into 2 tables, under the implied assumption that the indexes in them will match forever, as there is no reason for a delta to appear... Except one time when one of the insert's failed for this very reason, and from this moment onward every new picture submitted will have the description of the next picture displayed below it etc.... (on a side note, it takes awfull programming in the 1st place to make a program that even can fail in this way. Good programming is to never rely on risky assumptions with indexes)

3. A string may be intentionlly designed in such a way, that when it breaks up the 2nd and further parts of it make meaningfull Mysql commands. So basically, you are sending any commands you'd like to the server, just by typing them in the username, image description, and other user input areas on the website. You can explore the database, view data, modify data, or just delete the database alltogether. And sometimes mess up with other stuff too after compromising the database.... This type of attack is called an Injection, and it endangers every system that uses a database or basically everything which has untrusted user input

So we need to prevent strings from breaking up when submitted to the database. For this we escape them - we "freeze" the string as a single unit by disabling any objects in the string which may cause it to break up. But besides escaping, we can apply other rules like forbidding characters or words, uppercase or lowercase conversion, case sensitive or insensitive etc

One of the rules in this gallery was, case insensitive field for the filename. Possibly to make it compatible with WAMP (Windows/Apache/PHP/Mysql) servers too, under the assumption that WAMP poses the real problem with filenames, but not thinking of the possibility of causing a bug in LAMP servers as result



And besides, i dont think it is a good practice to keep the original filenames on the server filesystem and in the database anyway (besides the possuibility of bugs like this, what about users actually uploading files with identical names ? or uploading tricky stuff intentionally ? you have to solve that too). When i build stuff i generate names on the server which i am sure will be unique, uniform, and not have any questionable characters in them