FilePath.children() should return FilePath objects with unicodes in them instead of strs
|Reported by:||zooko||Owned by:|
This is an epic tale of a ticket. I'm sorry for that, but I didn't have time to make it shorter. During the middle chapter (where I'm arguing that Tahoe-LAFS ought to adopt filepath) you may think I've wandered off topic, but rest assured that we return to the topic of this ticket in the finale.
Summary: 1. Tahoe-LAFS would be improved by the use of filepath instead of its legacy path manipulation code. 2. FilePath.children is insufficient for Tahoe-LAFS's needs (because it doesn't decode bytes on Linux into unicodes), 3. Maye we could contribute code to help with that.
(Inspired by #2366.)
Twisted folks: for context, Zancas and I are experimenting with using filepath in Tahoe-LAFS, and David-Sarah questions whether filepath supports the handling of non-ASCII pathnames like Tahoe-LAFS already does. If filepath doesn't, switching to it might introduce a regression.
Zancas: A great way to tell whether it does would be to find a unit test that makes sure that it does. If you find one, and it currently passes, then great!--You know that it works. If you find one and it fails, then great!--You know that it doesn't. (This is why it can be useful to have a unit test that is known to go red and is marked as a "TODO" test.) If you've done a thorough scan and you're pretty sure that there is no test that would go red if this code had bugs with regard to unicode handling, then you know that this functionality isn't automatically tested, and we treat it as though it is likely to have bugs. Having searched myself in order to write this ticket (see below), I've learned that the answer is that filepath has, not bugs exactly, but limited functionality--FilePath.children returns a set of FilePath instances that have str-type paths instead of unicode-type paths.
All the filepath tests are here:
(I found that by grepping the twisted/test directory for "filepath".)
A quick scan through there confirms that, as exarkun and glyph mentioned on #4736, there aren't any tests for handling of non-ASCII characters.
The Tahoe-LAFS project has done extensive work, especially thanks to David-Sarah, and benefiting from some good advice I got a couple of years ago from Glyph and JP, to make sure that non-ASCII characters are supported in every way that makes sense for Tahoe-LAFS. We did this in a test-driven manner and have thorough unit tests. Perhaps they would be useful to filepath maintainers, and certainly they can be used to evaluate whether a Tahoe-LAFS-with-filepath had any regressions compared to a Tahoe-LAFS-with-os.path/__builtin__.open/shutil/etc.
There are many tests of other Tahoe-LAFS functionality which make sure it handles non-ASCII characters correctly, e.g.:
I'm looking at a sample of code in which we might replace Tahoe-LAFS's own filesystem manipulation with filepath. Here is an excerpt from our recent patch:
- tmpfile = self.statefname + ".tmp" - f = open(tmpfile, "wb") - pickle.dump(self.state, f) - f.close() - fileutil.move_into_place(tmpfile, self.statefname) + self.statefp.setContent(pickle.dumps(self.state))
Our code uses fileutil.move_into_place:
def move_into_place(source, dest): """Atomically replace a file, or as near to it as the platform allows. The dest file may or may not exist.""" if "win32" in sys.platform.lower(): remove_if_possible(dest) os.rename(source, dest)
Which uses remove_if_possible:
def remove_if_possible(f): try: remove(f) except: pass
(Ugh! A bare except:.)
Which uses a horrible function that I am rather ashamed of which has, I think, been in continuous use since the days of Mojo Nation:
def remove(f, tries=4, basedelay=0.1): """ Here is a superkludge to workaround the fact that occasionally on Windows some other process (e.g. an anti-virus scanner, a local search engine, etc.) is looking at your file when you want to delete or move it, and hence you can't. The horrible workaround is to sit and spin, trying to delete it, for a short time and then give up. With the default values of tries and basedelay this can block for less than a second. @param tries: number of tries -- each time after the first we wait twice as long as the previous wait @param basedelay: how long to wait before the second try """ try: os.chmod(f, stat.S_IWRITE | stat.S_IEXEC | stat.S_IREAD) except: pass for i in range(tries-1): try: return os.remove(f) except EnvironmentError, le: # XXX Tighten this to check if this is a permission denied error # (possibly due to another Windows process having the file open # and execute the superkludge only in this case. if not os.path.exists(f): return log.msg("XXX KLUDGE Attempting to remove file %s; got %s;" + \ "sleeping %s seconds" % (f, le, basedelay,)) time.sleep(basedelay) basedelay *= 2 return os.remove(f) # The last try.
Okay, so this is a great example of the benefits of using filepath instead of our own utility functions. The patch above eliminates code, some of which is bad code, in favor of invoking FilePath.setContents. But to the topic of this ticket: is this likely to introduce a regression in handling of non-ASCII characters?
In this particular example it is not likely to introduce a regression, because this particular code doesn't have mechanisms for handling non-ASCII characters any more than filepath does, and the current Tahoe-LAFS tests don't test whether this functionality handles non-ASCII characters.
In fact, for this example the filepath code and the current code result in almost the exact same sequence of calls to the exact same Python standard library functions, so if one has bugs in case of non-ASCII filenames, the other probably does too.
So what's an example of Tahoe-LAFS code which has been specifically crafted to handle non-ASCII characters and which has tests of that? I think the only such piece of code which filepath would replace is listdir_unicode. This is thoroughly tested by unit tests in test_encodingutil.py (as well as indirectly tested by other functional tests of Tahoe-LAFS).
Where do we use it? Here is a great example: the "tahoe backup" command lists children of a directory in order to back them all up: tahoe_backup.py. In addition to the unit tests of listdir_unicode itself, "tahoe backup" has tests of the "tahoe backup" functionality and tests of the command-line interface to it. The former includes tests of handling non-ASCII chars (look for the string "unicode") and the latter currently doesn't.
Okay, so this suggests something that Zancas and I can do: try the unit tests for listdir_unicode on FilePath.children, and assuming that they fail, then make sure not to replace any uses of listdir_unicode with FilePath.children. This may also prevent us from using filepath to manipulate the resulting children in the (client-side) backup code, but in the (server-side) storage code that Zancas and I are working on, this isn't a problem.
(In addition, of course, to keeping our eyes out for other potential regressions that I've overlooked in this analysis.)
This also suggests something that someone could contribute to filepath: the tests and the implementation which would cause FilePath.children to return an iterable of unicode objects. Are the filepath hackers interested in that?
Note that the current listdir_unicode raises exception if it gets a child name which can't be decoded in the nominal filesystem encoding. (This can't happen on Windows or Mac OS X.) I currently think that this behavior is strictly superior to the current behavior of FilePath.children, and so this should not be considered a regression from filepath's perspective, but I could be persuaded otherwise. I can imagine an API which handles both decodable and non-decodable child names, but I suspect that for most users raising exception on a non-decodable child name would be preferable. For extensive exploration of that issue in the context of Tahoe-LAFS, please see Tahoe-LAFS #371 (what to do with filenames that are illegal on some systems), which is also directly relevant to #2366.