Fedora Account System
Red Hat Associate
Red Hat Customer
thanks for https://koji.fedoraproject.org/koji/buildinfo?buildID=514852 - that is a amazing tool for webservers only one thing: it should not change owner/group/permissions i observed that there is a tempfile which is thrown away in case nothing to optimize and finally replaces the origin file which is nearly perfect behavior, but optimized files don't preserve permissions which makes it hard to use on webservers with gallery folders beause you get "permission denied" errors until fix perms at the end
A small patch is trivial, but I will write to the author first, to give benefit to everybody. Seems it worth to be included as the default behaviour, or at least as a program option.
thank you for the hyperfast feedback yes, should go upstream the results with default options are *impressive* because default is lossless and don't change images where nothing can be optimized - i consider the following command on the main webserver since a single folder of one website with highraiser became 200 MB smaller - *wow* find /www/ -type f -name \*.jpg -exec stat "{}" \;
It turns out that the permission fix is already included to the latest version (1.3.1) packaged today. I've tested a little bit, and everything is fine to me. Could you test 1.3.1 version on your side?
hm my testing was with jpegoptim-1.3.1-1.fc20.x86_64 because i did not know that tool until lokking arounf at fedora's koji with a "uhm what's that - sounds interesting" not 100% sure about chmod but the owner at the end is the one who fires up the command, IMHO something simlar to "cat tmpffile > originfile" in case there was something to optimize would do that (leading to not be 100% atomic but atomic enough for 99.9% of all cases)
errata the chmod is preserved but the owner is after jpegoptim the one running the command - that's not as bad as change permissions but change semantics because in case of let say owner "user1" with chmod 660 and change ownership to "user2" which is not in the same primary group "user1" may no longer have write permissions to a file he originally owned
FYI, comments from the author (combined from two messages): "I kinda like creating temp file and then replacing original using rename() call since that is pretty much atomic operation. I see your point about over/re-writing original to save owner, but to do that safely is quite bit of work, and if something goes wrong we might not be able to restore the original file back. Another point of view is that, if non-root user is modifying files belonging to others, its good that ownership changes so there is "audit trail" who was messing with the file(s)." ... I'm open to suggestion how to "safely" overwrite the existing file (to be able to preserve owner if user running jpegoptim is not the owner but has write access to the file). Since simply making backup, before overwriting original, might (in rare cases) end up with failure to write the new image over the old original file (if filesystem fills up, etc.), and be unable to "restore" the original file back. Creating temporary file and doing rename() to replace original file should be safer, as it should alway leave original file intact if rename() fails." Another thing, I have to say that jpegoptim-1.4.0 has been released today, may be there some changes on it (I haven't checked yet, just read the new version announce).
cool to see a responsive and vital upstream! the owner thing is not that big problem, i worked around it sucessfully with some php-shell-script magic, my idea would be: * we already know that we can write to the directory because otherwise the current temp-file would and does fail * we know the owner and user currently running * if both are not identical * make a "origin-name.bkp" with the current owner * cat temp-file > origin-name * if no error remove "origin-name.bkp" * in case that fails rename "origin-name.bkp" back to "origin-name" and raise a warning, in that case we still have a owner-change but only if something goes wrong the overwrite itself is not 100% atomic, maybe that behavior could be optional with a command-line param defaulting to disabled
jpegoptim-1.4.1 packages have been pushed to testing, everyone is encouraged to test and give opinions.
cool - as root now it even keeps owner/group, that was my first test before create that bugreport because a previously by my user owned file got owner by root and was no lomger accessable by myself (yes i know normally you must not do that as root) __________________________________________________________ [harry@srv-rhsoft:/data/jpegoptim]$ ls insgesamt 10M -rw-rw-rw- 1 wwwcron apache 1,1M 2014-05-28 21:10 1.jpg -rw-rw-rw- 1 wwwcron apache 1,2M 2014-05-28 21:05 2.jpg -rw-rw-rw- 1 wwwcron apache 1,1M 2014-05-28 21:05 3.jpg -rw-rw-rw- 1 wwwcron apache 1022K 2014-05-28 21:05 4.jpg -rw-rw-rw- 1 wwwcron apache 1,2M 2014-05-28 21:05 5.jpg -rw-rw-rw- 1 wwwcron apache 1,4M 2014-05-28 21:05 6.jpg -rw-rw-rw- 1 wwwcron apache 1021K 2014-05-28 21:05 7.jpg -rw-rw-rw- 1 wwwcron apache 1009K 2014-05-28 21:05 8.jpg -rw-rw-rw- 1 wwwcron apache 1,2M 2014-05-28 21:05 9.jpg [harry@srv-rhsoft:/data/jpegoptim]$ jpegoptim --all-progressive *.jpg 1.jpg 2244x1535 24bit N Exiff JFIF [OK] 1085088 --> 1047261 bytes (3.49%), optimized. 2.jpg 2244x1535 24bit N Exiff JFIF [OK] 1206097 --> 1159387 bytes (3.87%), optimized. 3.jpg 1535x2244 24bit N Exiff JFIF [OK] 1144496 --> 1103736 bytes (3.56%), optimized. 4.jpg 2244x1535 24bit N Exiff JFIF [OK] 1046403 --> 1009889 bytes (3.49%), optimized. 5.jpg 1535x2244 24bit N Exiff JFIF [OK] 1235005 --> 1181111 bytes (4.36%), optimized. 6.jpg 2244x1535 24bit N Exiff JFIF [OK] 1406650 --> 1341386 bytes (4.64%), optimized. 7.jpg 1535x2244 24bit N Exiff JFIF [OK] 1044991 --> 1003762 bytes (3.95%), optimized. 8.jpg 1535x2244 24bit N Exiff JFIF [OK] 1032436 --> 991044 bytes (4.01%), optimized. 9.jpg 2244x1535 24bit N Exiff JFIF [OK] 1171305 --> 1125889 bytes (3.88%), optimized. [harry@srv-rhsoft:/data/jpegoptim]$ ls insgesamt 9,6M -rw-rw-rw- 1 harry apache 1023K 2014-05-28 21:12 1.jpg -rw-rw-rw- 1 harry apache 1,2M 2014-05-28 21:12 2.jpg -rw-rw-rw- 1 harry apache 1,1M 2014-05-28 21:12 3.jpg -rw-rw-rw- 1 harry apache 987K 2014-05-28 21:12 4.jpg -rw-rw-rw- 1 harry apache 1,2M 2014-05-28 21:12 5.jpg -rw-rw-rw- 1 harry apache 1,3M 2014-05-28 21:12 6.jpg -rw-rw-rw- 1 harry apache 981K 2014-05-28 21:12 7.jpg -rw-rw-rw- 1 harry apache 968K 2014-05-28 21:12 8.jpg -rw-rw-rw- 1 harry apache 1,1M 2014-05-28 21:12 9.jpg __________________________________________________________ [root@srv-rhsoft:/downloads]$ ls insgesamt 10M -rw-r----- 1 harry verwaltung 1,1M 2014-05-28 21:01 1.jpg -rw-r----- 1 harry verwaltung 1,2M 2014-05-28 21:01 2.jpg -rw-r----- 1 harry verwaltung 1,1M 2014-05-28 21:01 3.jpg -rw-r----- 1 harry verwaltung 1022K 2014-05-28 21:01 4.jpg -rw-r----- 1 harry verwaltung 1,2M 2014-05-28 21:01 5.jpg -rw-r----- 1 harry verwaltung 1,4M 2014-05-28 21:01 6.jpg -rw-r----- 1 harry verwaltung 1019K 2014-05-28 21:01 7.jpg -rw-r----- 1 harry verwaltung 1008K 2014-05-28 21:01 8.jpg -rw-r----- 1 harry verwaltung 1,2M 2014-05-28 21:01 9.jpg [root@srv-rhsoft:/downloads]$ jpegoptim --all-progressive *.jpg 1.jpg 2244x1535 24bit N Exiff JFIF [OK] 1085572 --> 1047393 bytes (3.52%), optimized. 2.jpg 2244x1535 24bit N Exiff JFIF [OK] 1206236 --> 1159220 bytes (3.90%), optimized. 3.jpg 1535x2244 24bit N Exiff JFIF [OK] 1144755 --> 1103812 bytes (3.58%), optimized. 4.jpg 2244x1535 24bit N Exiff JFIF [OK] 1046293 --> 1009376 bytes (3.53%), optimized. 5.jpg 1535x2244 24bit N Exiff JFIF [OK] 1234838 --> 1180585 bytes (4.39%), optimized. 6.jpg 2244x1535 24bit N Exiff JFIF [OK] 1407569 --> 1342060 bytes (4.65%), optimized. 7.jpg 1535x2244 24bit N Exiff JFIF [OK] 1043405 --> 1003535 bytes (3.82%), optimized. 8.jpg 1535x2244 24bit N Exiff JFIF [OK] 1031243 --> 989983 bytes (4.00%), optimized. 9.jpg 2244x1535 24bit N Exiff JFIF [OK] 1171553 --> 1125769 bytes (3.91%), optimized. [root@srv-rhsoft:/downloads]$ ls insgesamt 9,6M -rw-r----- 1 harry verwaltung 1023K 2014-05-28 21:02 1.jpg -rw-r----- 1 harry verwaltung 1,2M 2014-05-28 21:02 2.jpg -rw-r----- 1 harry verwaltung 1,1M 2014-05-28 21:02 3.jpg -rw-r----- 1 harry verwaltung 986K 2014-05-28 21:02 4.jpg -rw-r----- 1 harry verwaltung 1,2M 2014-05-28 21:02 5.jpg -rw-r----- 1 harry verwaltung 1,3M 2014-05-28 21:02 6.jpg -rw-r----- 1 harry verwaltung 981K 2014-05-28 21:02 7.jpg -rw-r----- 1 harry verwaltung 967K 2014-05-28 21:02 8.jpg -rw-r----- 1 harry verwaltung 1,1M 2014-05-28 21:02 9.jpg
Appeared to be fixed with BZ#1176901. See https://github.com/tjko/jpegoptim/commit/36f0e628bcccd852f57a7ec2081dd7f14c757b22 and newer; any feedback is appreciated.
Pushed to stable and closed.