Skip Menu |

This queue is for tickets about the Net-Flickr-Backup CPAN distribution.

Report information
The Basics
Id: 37858
Status: open
Priority: 0/
Queue: Net-Flickr-Backup

People
Owner: ascope [...] cpan.org
Requestors: looseheadprop1 [...] gmail.com
Cc: tsibley [...] cpan.org
AdminCc:

Bug Information
Severity: Critical
Broken in: 2.991
Fixed in: (no value)



Subject: Two weired problems with Net-Flickr-Backup
Date: Tue, 22 Jul 2008 20:58:14 +0200
To: bug-Net-Flickr-Backup [...] rt.cpan.org
From: tomasz przechlewski <looseheadprop1 [...] gmail.com>
First problem is that Net-Flickr-Backup dies Can't escape \x{0119}, try uri_escape_utf8() instead at \ /usr/local/share/perl/5.8.8/Net/Flickr/RDF.pm line 1497 it looks like it can't escape geo-names of the sort: http://www.flickr.com/places/Poland/Pomorskie/Rębiechowo ^^^ I have changed uri_escape to URI::Escape::uri_escape_utf8 twice in RDF.pm. It now works but I am not sure if my simple solution is correct (too simple to be correct I suspect). The other problem is even stranger: some URIs generated by Net-Flickr-Backup are invalid: example: http://www.flickr.com/photos/tprzechlewski/2301070397/ RDF of this photo is appended below rdf:resource is screwed up (photo id?). Cant figure why... I have over 5000 photos, uploaded from 2004. It looks like those screwed URIs are generated for 2008 photos only. Earlier ones seems to be OK... strange...have no idea why... --tomek ======================================================================= <rdf:RDF xmlns:a="http://www.w3.org/2000/10/annotation-ns" xmlns:nfr_geo="http://www.machinetags.org/wiki/geo#lon" xmlns:exif="http://nwalsh.com/rdf/exif#" xmlns:mt="x-urn:flickr:machinetag:" xmlns:exifi="http://nwalsh.com/rdf/exif-intrinsic#" xmlns:cc="http://web.resource.org/cc/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:places="http://www.flickr.com/places/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:acl="http://www.w3.org/2001/02/acls#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:computer="x-urn:linux:" xmlns:flickr="x-urn:flickr:" Show quoted text
>
<rdf:Description rdf:about="http://www.flickr.com/geo/Poland/Pomorskie/Sopot/Sopot"> <rdfs:seeAlso rdf:resource="http://www.flickr.com/places/Poland/Pomorskie/Sopot"/> </rdf:Description> <flickr:user rdf:about="http://www.flickr.com/people/20425995@N00"> <foaf:mbox_sha1sum>7d2f0a9f3077f42659185f94aad0698473c0340a</foaf:mbox_sha1sum> <foaf:name>tomasz przechlewski</foaf:name> <foaf:nick>hr.icio</foaf:nick> </flickr:user> <rdf:Description rdf:about="x-urn:linux:user"> <rdfs:subClassOf rdf:resource="http://xmlns.com/foaf/0.1/Person"/> </rdf:Description> <flickr:tag rdf:about="http://www.flickr.com/photos/tags/geo:lon=18550000"> <skos:altLabel>18.550000</skos:altLabel> <skos:broader rdf:resource="http://www.machinetags.org/wiki/geo#lon"/> <skos:prefLabel rdf:resource="geo:lon=18550000"/> </flickr:tag> <flickr:machinetag rdf:about="http://www.machinetags.org/wiki/geo#loc"> <mt:predicate>loc</mt:predicate> <mt:namespace>geo</mt:namespace> <dc:isReferencedBy rdf:resource="http://www.flickr.com/photos/20425995@N00/-1993896899"/> </flickr:machinetag> <computer:user rdf:about="x-urn:brightstar#tomek"> <foaf:name>tomek,,,</foaf:name> <foaf:nick>tomek</foaf:nick> </computer:user> <flickr:machinetag rdf:about="http://www.machinetags.org/wiki/geo#lat"> <mt:predicate>lat</mt:predicate> <mt:namespace>geo</mt:namespace> <dc:isReferencedBy rdf:resource="http://www.flickr.com/photos/20425995@N00/-1993896899"/> </flickr:machinetag> <flickr:tag rdf:about="http://www.flickr.com/photos/20425995@N00/tags/geo:lat=54439639"> <skos:altLabel>54.439639</skos:altLabel> <dc:creator rdf:resource="http://www.flickr.com/people/20425995@N00"/> <skos:broader rdf:resource="http://www.flickr.com/photos/tags/geo:lat=54439639"/> <skos:prefLabel rdf:resource="geo:lat=54.439639"/> <skos:altLabel rdf:resource="geo:lat=54439639"/> </flickr:tag> <flickr:tag rdf:about="http://www.flickr.com/photos/20425995@N00/tags/crocus"> <skos:prefLabel>crocus</skos:prefLabel> <dc:creator rdf:resource="http://www.flickr.com/people/20425995@N00"/> <skos:broader rdf:resource="http://www.flickr.com/photos/tags/crocus"/> </flickr:tag> <dcterms:StillImage rdf:about="http://farm3.static.flickr.com/2171/2301070397_9a27344a68_m.jpg"> <dcterms:relation>Small</dcterms:relation> <exifi:height>180</exifi:height> <exifi:width>240</exifi:width> <dcterms:isVersionOf rdf:resource="http://farm3.static.flickr.com/2171/2301070397_1ea9383007_o.jpg"/> <rdfs:seeAlso rdf:resource="http://www.flickr.com/photos/20425995@N00/-1993896899"/> <rdfs:seeAlso rdf:resource="http://www.flickr.com/photos/20425995@N00/-1993896899#exif"/> </dcterms:StillImage> <rdf:Description rdf:about="#"> <dcterms:hasVersion>2.1:1216671629</dcterms:hasVersion> <dc:created>2008-07-21T22:20:29+0200</dc:created> <dc:creator rdf:resource="http://search.cpan.org/dist/Net-Flickr-RDF-2.1"/> <a:annotates rdf:resource="http://www.flickr.com/photos/20425995@N00/-1993896899"/> </rdf:Description> ....
From: looseheadprop1 [...] gmail.com
On Wto. 22 Lip. 2008, 14:58:50, looseheadprop1@gmail.com wrote: Show quoted text
> First problem is that Net-Flickr-Backup dies >
Seems nobody backups photos with Net-Flickr-Backup at least on machine with 32bit integer:-( printf/sprintf ("%d", photo_id) has no chance to work as photo_id exceeds Perl integer limit (cf http://andrewsblog.org/2007/12/30/use-bigint-for-flickr-photo-ids/). I have changed %d to %s. BTW seems no reason to stick to %d or %ld... Perhaps I am wrong...
From: looseheadprop1 [...] gmail.com
On Pon. 04 Sie. 2008, 06:21:34, looseheadprop1@gmail.com wrote: Show quoted text
> On Wto. 22 Lip. 2008, 14:58:50, looseheadprop1@gmail.com wrote:
> > First problem is that Net-Flickr-Backup dies > >
A supplement. I have searched for the spec of photo_id and none found, BUT http://www.flickr.com/services/api/misc.overview.html Note: The Flickr API exposes identifiers for users, photos, photosets and other uniquely identifiable objects. These IDs should always be treated as opaque strings, rather than integers of any specific type. The format of the IDs can change over time, so relying on the current format may cause you problems in the future. Obviously the author of Net-Flickr-Backup was unaware of the above mentioned note...
The author (that would be me :-) pleads guilty, especially since he actually works at Flickr. I will try to get a patch out tonight or tomorrow. Thanks for the note. On Mon Aug 04 06:44:25 2008, looseheadprop1@gmail.com wrote: Show quoted text
> On Pon. 04 Sie. 2008, 06:21:34, looseheadprop1@gmail.com wrote:
> > On Wto. 22 Lip. 2008, 14:58:50, looseheadprop1@gmail.com wrote:
> > > First problem is that Net-Flickr-Backup dies > > >
> A supplement. > > I have searched for the spec of > photo_id and none found, BUT > > http://www.flickr.com/services/api/misc.overview.html > > Note: The Flickr API exposes identifiers for users, photos, photosets > and other uniquely identifiable objects. These IDs should always be > treated as opaque strings, rather than integers of any specific type. > The format of the IDs can change over time, so relying on the current > format may cause you problems in the future. > > Obviously the author of Net-Flickr-Backup was unaware of > the above mentioned note...
Subject: Re: [rt.cpan.org #37858] Two weired problems with Net-Flickr-Backup
Date: Wed, 06 Aug 2008 09:00:17 +0200
To: bug-Net-Flickr-Backup [...] rt.cpan.org
From: looseheadprop1 [...] gmail.com
Aaron Straup Cope via RT pisze: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=37858 > > > The author (that would be me :-) pleads guilty, especially since he > actually works at Flickr. > > I will try to get a patch out tonight or tomorrow. Thanks for the note. >
:-) thanks --tomek
This bug affects not only IDs throughout the RDF data, but also the filenames that are used for ALL files. Fixing this is very easy. The tricky part is that fixing it will break the whole incremental update code. Users will need to essentially delete their entire backup and start anew, or live with the old, wrongly named data. Leaving the old data also means that when old photos are updated, their data will be duplicated on disk. One possible solution to this is a migration tool, or trying to automatically detect and fix it within the module, but that seems like taking too much control out of the users' hands. For some this may be a small issue (the rest of the metadata is fine and of course the images are), but for others incorrect IDs mean being totally unable to ever associate an ID you have with the image it used point to.
This bug depends on ticket #53000 in the Net-Flickr-RDF queue, but I don't have the permissions to link it properly at this time. https://rt.cpan.org/Ticket/Display.html?id=53000