Up loading photos from iPhone 5 (answered)

LEWD

User
Credits
42CR
Hey
I've tried to up load some photos of my machines from my iPhone
But can only put up one picture when the 2 nd is posted says that a file of that name has already been uploaded it says to rename photo can't seem to find an option on my phone or the site
Prob just me being crap but I can't even do it over pm ? Thanks LEWD2013-03-21 22:30:42
 

Nintendo Arcade

AL’s Arcade
Staff member
vacBacker
Feedback
4 (100%)
Credits
660CR
LEWD said:
Hey
I've tried to up load some photos of my machines from my iPhone
But can only put up one picture when the 2 nd is posted says that a file of that name has already been uploaded it says to rename photo can't seem to find an option on my phone or the site
Prob just me being crap but I can't even do it over pm ? Thanks
I have the same problem mate
I use a imgupr now
 

Alpha1

Do the Shake and 'VAC
Staff member
vacBacker
Feedback
94 (99%)
Credits
5,361CR
Hi,

I believe the issue is when you up a photo the iPhone/iOS calls it the same file name every time. Which of course causes an issue as if you have uploaded a picture already with that standard name.
 

trm

Who loves you, and who do you love?
Feedback
2 (100%)
Credits
2,876CR
BristolMartin said:
Yes its a forum bug. VBulletin!

It's not a forum bug this time. It's as Oll says - the offer from the iPhone has photo.jog as the file name each time. It's as much a WW bug as it is a file system bug for not accepting two files in the same directory with the same name...
 

trm

Who loves you, and who do you love?
Feedback
2 (100%)
Credits
2,876CR
I'm not sure what that post has to do with this other than it mentions iPhones?

This isn't a bug - it's 100% down to the iPhone doing file names weirdly. It offers every upload with the same name, WW accepts the upload until it tries to write to the server file system where it receives an error when it tries to create a new file that collides with another.

Anyone can upload one file from an iPhone to here, but the second will fail unless you go into File Manager and remove the first upload. If you don't believe this easily reproducible behaviour, run a network sniffer on the HTTP session between the iPhone and the server and you'll see the photo.jpg every time.

We could modify the uploader part of WW to append a random number to every file upload to avoid naming collisions, but that's overall a worse idea Han having to use imgupr.
 

BristolMartin

Active member
vacBacker
Feedback
0 (50%)
Credits
382CR
trm said:
I'm not sure what that post has to do with this other than it mentions iPhones?

This isn't a bug - it's 100% down to the iPhone doing file names weirdly. It offers every upload with the same name, WW accepts the upload until it tries to write to the server file system where it receives an error when it tries to create a new file that collides with another.

Anyone can upload one file from an iPhone to here, but the second will fail unless you go into File Manager and remove the first upload. If you don't believe this easily reproducible behaviour, run a network sniffer on the HTTP session between the iPhone and the server and you'll see the photo.jpg every time.

We could modify the uploader part of WW to append a random number to every file upload to avoid naming collisions, but that's overall a worse idea Han having to use imgupr.

So coding around a bug is worse than every other user on the forum having to use a 3rd party piece of software? Totally your choice of course but that doesn't sound like a solution to a problem, more a workaround.
 

trm

Who loves you, and who do you love?
Feedback
2 (100%)
Credits
2,876CR
There are a number of reasons why altering the code isn't a good idea. It's nothing to do with "imgupr is ok, let everyone use that".

First is that we'd have to modify core WW code. All of our custom work is sensibly split off into a UKVAC branch, so we don't break upgrades.

If we just appended a random number to the file name we'd still have a chance of file name collisions. The likelihood would increase as more photos were uploaded and so then we'd end up with a much more random failure.

One way around that would be to add a hash to the file name, but then we're going to be adding 100+ bytes to each file name. Does WW have any short file name length buffers? And short string manipulation routines? Hopefully not but hope isn't generally something I look forward to in a code release
smiley1.gif
and a full code audit is impractical. Even if we just used a hash as the entire file name we'd make it impossible for anyone to recognise a file by name so they'd have to click through File Manager to look for some old pic.

And once the uploaded had been modified to hash and concatenate we'd have to check the following code path that ties image upload to insertion plus any other part of the File Manager. By which point we'd have touched a non-trivial percentage of the WW code so that when they release a supported patch, we can't apply it because we're running a weirdly non-standard hacked up version.

It's honestly not that we can't be arsed - it's that the available solutions all have a degree of complexity and the imgupr has the least when considered against the requirements of all forum members.
 

BristolMartin

Active member
vacBacker
Feedback
0 (50%)
Credits
382CR
I fully understand. Its always a tricky decision. My company lives by the facebook motto which is move fast, break stuff and fix it, but what works for one doesn't always work for another. My only comment is that *IF* I were competing whit a competitive Jamma forum, I would make it as attractive and easy as possible, in the shortest time frame possible for my users to post easily.
 

trm

Who loves you, and who do you love?
Feedback
2 (100%)
Credits
2,876CR
I recognise your point completely, and as an iOS user it does cause a tiny annoyance that I have a couple of extra steps to follow. But (and this is completely hypothetical) say I had been involved in moderating another forum that also ran WW and had lived through the stress caused by all the custom code causing a very old version lock-in when members were asking why we didn't support any of the newer features that seemed to be very popular elsewhere, I'd deeply consider the cost/benefit options of breaking future upgrades.

It's tricky - we don't seem to have a huge number of people experiencing inconvenience from this and the analytics suggest that iOS users already figured their own workarounds or just haven't noticed/raised it.

For a variety of reasons this isn't going to be a permanent problem, but at the current time it doesn't look like the "f**k it, fix it" methodology would be appreciated by most of our members. Recent influxes of members may change the bias towards greater risk and faster feature updates so we do watch for this and will do our best based on data.

And then there's always a potential client-side fix
smiley2.gif
 
Top