Filesystem paths

Aaron Bentley aaron.bentley at utoronto.ca
Wed Apr 26 17:16:42 BST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On 26/04/2006, at 1:53 PM, Aaron Bentley wrote:
> +Transports work in URLs.  Take note that URLs are by definition only
> +ASCII - the decision of how to encode a Unicode string into a URL  must be
> +taken at a higher level, typically in the Store.

This doesn't look accurate.  AFAIK, we do unicode-to-utf-8 conversions
in the transport layer.  The store escaping thing is a separate issue.

> +A similar edge case is that the url ``http://foo/sweet%2Fsour" contains
> +one directory component whose name is "sweet/sour".  The escaped  slash is
> +not a directory separator.

(although many, many pieces of software will treat it as one, including
conformant SFTP implementations)

> So LocalTransport.abspath shouldn't be calling osutils.abspath, but 
> rather should be manipulating URL objects?  Then we can see that
> 
>   file:///c|/
> 
> has no "up"?

Right.  We can test going up from '/' under *nix, while we can't test
going up from 'C:\', because osutils (correctly, I believe) treats '/'
as top-level root under *nix.  But URLs are URLs are URLs.

>> OTOH, I don't think it's appropriate to be using transports to access
>> working trees, and since that's the bug you encountered, I suggest
>> that's what we should fix-- build_tree should either be implemented in
>> terms of POSIX, or it should translate paths to urls before using them
>> with Transport.
> 
> 
> Can you tell me more about why it's not appropriate?  Is it because 
> Transports should focus on supporting just what is needed for control 
> file access?

To some extent, this is Arch residue-- that system has a very clean
distinction between archive-access methods (the PFS) and
filesystem-access methods (the virtual-unix subsystem).

The idea was that PFS supported only what was available on all supported
access methods-- read, write, list*, mkdir, rmdir, and not much else.

Whereas the virtual-unix subsystem supported a richer command set that
included, for example, stat and chmod.

However, our Transports do support stat and chmod-- I guess the question
is whether we want to require this.  Would that preclude us from
supporting additional access methods that we want to support?

If the subset of functionality supported by all our transports is such
that we can implement TreeTransform, the hashcache, etc. on top of them,
then perhaps I'm being too rigid.  There is desire to support remote
access to working trees in some form, and this could be it.

Another argument is that Transports are unfamiliar to most developers,
and so they introduce an unwarranted barrier to contribution.  On the
other hand, it might make sense to use TreeTransform for our operations,
which would be a new API anyhow.

In some ways, it might be desirable to permit non-unicode paths when
working with working trees.  We require versioned files to have unicode
names, but I don't think we necessarily should require that unversioned
files have unicode pathnames.  At the moment, I expect that things will
explode in that situation, anyhow.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFET5zq0F+nu1YWqI0RAohVAJ4oCIL4H6DKXE50Fb75+mfgkN8rmACfYFyH
xPGCYh6LmkokC7Rvq8fsnSE=
=Xdxp
-----END PGP SIGNATURE-----




More information about the bazaar mailing list