W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Re: New filesystem/directory API proposal

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 3 Feb 2010 11:52:02 +0000 (UTC)
To: Eric Uhrhane <ericu@google.com>
Cc: Michael Nordman <michaeln@google.com>, public-device-apis@w3.org
Message-ID: <Pine.LNX.4.64.1002020707030.21600@ps20323.dreamhostps.com>
On Mon, 1 Feb 2010, Eric Uhrhane wrote:
> On Mon, Feb 1, 2010 at 2:53 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Mon, 1 Feb 2010, Michael Nordman wrote:
> >>
> >> What happens when some external program generates an invalidly name 
> >> file in the directory being employed by the WebFS (assuming an impl 
> >> is doing the obvious thing and directly mapping a native directory to 
> >> the root of the WebFS)?
> >
> > There's an easy way around this one -- define the mapping such that 
> > there aren't any invalid names.
> 
> Are you thinking of something like the MS "foo~1" convention?

That's not a mapping, that's just hiding the real name and using a 
placeholder in the filesystem.

No, I mean a mapping. For example, suppose the restriction was that the 
file system couldn't have "/" characters in the name, and the API couldn't 
have ":" characters in the name. You could define a trivial mapping where 
/ in the API and : in the filesystem were equivalent.

Or suppose you had a filesystem that couldn't have A-E in the name, and an 
API that couldn't have 0-3 in the name. You could define a mapping by 
artificially restricting the API further so that 4 was also not allowed, 
and then simply mapping A-E to 0-4.

Or suppose you had a filesystem that couldn't have any of 0-3, and you had 
an API that allowed anything at all except A and B. You could define a 
mapping wherein any sequence of the characters 0-3 was converted to a 
sequence of A and B characters wherein each run of A characters represents 
a character 1-3 based on whether there's 1, 2, or 3 As, and each B 
separates runs of characters; two Bs in a row, as well as a B at the start 
or end, implies a 0. Three AAAs implicitly have a B after them. The 
opposite mapping goes the other way.

So:

   As seen in the filesystem...       As seen in the API...
   testAtest                          test1test
   testBtest                          test0test
   testAAAABBBAtest                   test31001test
   testAAABtest                       test30test
   __ABAB_BBAA__                      __110_002__

(Obviously the characters wouldn't actually be 0-3 or A and B.)

Generally speaking you can convert any set of strings with one alphabet 
into a set of strings in another alphabet in a 1:1 manner. If both 
alphabets have a large common set of characters, and both have at least 2 
characters that the other alphabet does not, you can always reduce the 
problem to the 0/1/2/3/A/B example above, for instance. The trick is 
getting the mapping to be something that preserves most of the filename; 
it's of course pretty trivial to come up with a mapping that is 1:1 
between two specific alphabets but where the two filenames have no 
apparent relationship.


> It's quite doable, obviously, but it can have unintuitive effects when 
> you move multiple "difficult" files into and out of a directory, when 
> names clash with files /actually/ called "foo~1", when you want to copy 
> a file to another directory without changing its name, when you want to 
> move "illegal:filename.txt" to "illegal:filename.txt.bak", and when 
> you're managing the files both in the browser and via the external 
> program that's created the awkward name.  And I'm sure I'm missing some 
> cases.

I don't think any of those are really problems in the example case I gave 
except the "managing the files both in the browser and via the external 
program that's created the awkward name" case.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 3 February 2010 11:52:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC