Error - file name too long (file cache on ecryptfs)

[GoogleCodeExporter]

What steps will reproduce the problem?

$ geotoad --distanceMax=18.6 'N 39 51.833 E 2 56.660'

What is the expected output? What do you see instead?
[If possible, include the last ~10--20 lines of verbose output.]

( o ) Performing location search for N 39 51.833 E 2 56.660 (constraining to 
18.6 miles)
/usr/share/geotoad/lib/shadowget.rb:186:in `initialize': File name too long - 
/home/martin/.geotoad/cache/maps.google.com/maps/geo_q_N_39_51.833_E_2_56.660_ou
tput_csv_oe_utf8_sensor_false_key_ABQIAAAAfYtme_pyDnFOuJLGZiXvPxRuVmV2GDBxlUzS4T
l93rTyZWZiOBRL-7BgtHIJc12HxIcS5teMAlIPzw (Errno::ENAMETOOLONG)
    from /usr/share/geotoad/lib/shadowget.rb:186:in `open'
    from /usr/share/geotoad/lib/shadowget.rb:186:in `fetch'
    from /usr/share/geotoad/interface/../lib/geocode.rb:51:in `get_url'
    from /usr/share/geotoad/interface/../lib/geocode.rb:17:in `lookup_location'
    from /usr/share/geotoad/lib/search.rb:32:in `setType'
    from /usr/bin/geotoad:195:in `downloadGeocacheList'
    from /usr/bin/geotoad:180:in `each'
    from /usr/bin/geotoad:180:in `downloadGeocacheList'
    from /usr/bin/geotoad:627

What version of the product are you using? On what operating system?
[Did you check you're using the latest version?]

GeoToad 3.14.3 (i486-linux-1.8.7)

Installed via latest .deb on Ubuntu maverick.

Please provide any additional information below.

Original issue reported on code.google.com by martin.b...@gmail.com on 29 Mar 2011 at 6:23

[GoogleCodeExporter]

I think I've resolved this by changing the 250 character limit in lines 107 and 
109 of shadowget.rb to 150 instead. Not sure why this limit wasn't sufficient - 
perhaps because I'm using ecryptfs...?

Original comment by martin.b...@gmail.com on 29 Mar 2011 at 6:43

[GoogleCodeExporter]

http://lwn.net/Articles/305931/
"Because filename encryption expands the length of the filename during
the encoding stage, eCryptfs will not properly handle filenames that
are already near the maximum filename length."

- this seems to explain what you are seeing.
Note that the file name (without the preceding path) is 151 characters long, 
meaning you just touched the limit. (What's the file name length now, after 
your changes?)

Some suggestions to work around this:
- You might have dropped the N and E prefixes for the coordinates (as both are 
the "positive" default). (Coordinate representations are more flexible now than 
they used to be.)
- Another way to avoid this issue would be to set GEO_DIR (let it point to a 
directory that's not in ecryptfs).

[A more general solution would involve determining a maximum file name length 
for the filesystem(s) being used for cache and output - perhaps a limit in a 
strict sense doesn't even exist, depending on the encoding algorithm? Reading 
fs/ecryptfs/{crypto,keystore}.c doesn't help me much at the moment...]

I'd suggest to change the status of this issue to "WontFix". helixblue, any 
objections?

Original comment by Steve8x8 on 30 Mar 2011 at 10:58

• Changed title: Error - file name too long (file cache on ecryptfs)

[GoogleCodeExporter]

Thanks for the helpful reply. The filename now is 149 characters, so that must 
be only just below the threshold.

The discussion at https://bugs.launchpad.net/ecryptfs/+bug/344878 seems to 
suggest that this limitation will be going away in future anyway.

The only thing I would suggest is that geotoad could catch the exception and 
shorten the filename when it occurs?

Original comment by martin.b...@gmail.com on 31 Mar 2011 at 11:07

[GoogleCodeExporter]

Interesting discussion. (The solution on ecryptfs's side requires xattr support 
which isn't available for all lower filesystems.)
Iteratively shortening the filename in the app might resolve the issue, indeed. 

Until someone comes up with a 8.3 FAT fs. :D

BTW, something I forgot: a "location" query (the default if the "-q" option 
isn't specified) will ask Google Maps for "improved" coordinates (some "real 
object" in the vicinity).

In your case, as you can check using
http://maps.google.com/maps?q=N+39+51.833+E+2+56.660&z=12
the new target will be pretty far away - in some cases, the distance may even 
exceed the search radius!
(Why it makes a difference whether you use the URL, or press enter again in the 
search input field (6 km vs 600 m), is still a mystery to me - but you get the 
idea?)

Better use "coord" queries when coordinates are already available - GeoToad is 
supposed to understand way more coordinate representations than it did half a 
year before (SVN revision 770, fixing issue 151).
As a side effect, this avoids maps.google.com accesses (and creation of 
long-named files)...

Original comment by Steve8x8 on 1 Apr 2011 at 8:52

[GoogleCodeExporter]

... also, how about simply running the filename through a hashing algorithm to 
shorten it while still maintaining uniqueness.

Anyway, thanks for the hints regarding using coord. I hadn't realised that 
Google Maps shifted co-ordinates to such a large extent. (Interestingly, if you 
change the zoom value at the end of the URL to 16 or 17, the target gets much 
closer to the supplied coordinates. I'm guessing that what Google Maps 
considers to be a nearby "real object" varies according to the scale of the map 
requested).

Original comment by martin.b...@gmail.com on 1 Apr 2011 at 11:08

[GoogleCodeExporter]

Re Google Maps' interpretation of search items: Try to search for something 
large (like a continent, or a big lake) and play with zoom levels. What will 
happen? ;)

Re ecryptfs: I'd like to know what happens to this issue as ecryptfs 
development proceeds, therefore leaving it in limbo.

Original comment by Steve8x8 on 4 Aug 2011 at 9:20

[GoogleCodeExporter]

What's the current state of ecryptfs, with respect to this problem?

Original comment by Steve8x8 on 2 Mar 2012 at 2:10

[GoogleCodeExporter]

Any news? (Setting status to "Info Needed".)

Original comment by Steve8x8 on 23 Apr 2012 at 11:56

• Changed state: InfoNeeded

[GoogleCodeExporter]

Closing as "Won't Fix".

(Moving files to the .Trash will even fail on ext3 file systems - if the file 
name is too long for a ".trashinfo" suffix. Rule #1: If it hurts, don't do it. 
Find another way instead.)

Sorry for the bad news...

Original comment by Steve8x8 on 4 Sep 2012 at 11:37

• Changed state: WontFix