[darcs-users] Re: Whitespace in filenames

Zack Brown zbrown at tumblerings.org
Sun Aug 3 18:40:08 UTC 2003


On Sat, Aug 02, 2003 at 06:12:59AM -0400, David Roundy wrote:
> Well, there's a problem in that I don't know that it's possible or
> practical to check against the conventions of the filesystem you're pulling
> to.  Among other things, the repository might span more than one
> filesystem, each of which has different filename restrictions.  And on the
> principle of letting users do whatever they want, that should be ok.  So I
> don't see myself trying to figure out what the filename restrictions of a
> given filesystem are to check on pull.  Patches to do this would be
> welcome, but it doesn't interest me, and I don't see how it can guarantee
> that the patch will apply properly (that is, that it will write to the
> desired file).

How about this: try to create the file, then check to see if it was
properly created. If not, you know there's an incompatibility, and you
can punt to the user. That way you don't need to know exactly which
filesystem you're dealing with, but you still catch all violations.

> The other problem is that for a repository to be portable, no file can
> *ever* have had a filename portability problem.  Normally when a project
> has a filename policy, I would think that they would enforce it by renaming
> any files that violate it, but this wouldn't be enough to acheive
> portability.  The patches would need to be unrecorded, which, for example,
> the darcs-patcher won't do--mostly to avoid race conditions with people
> pulling while you unrecord, but also because I think unrecording publicly
> available patches is bad policy.  Anyhow, the point is recording a
> "non-portable" patch is a very serious issue--if it goes unnoticed, and
> later the repo is intended to be used on another platform, there are only
> two options: either start a new repository or manual excise all mention of
> the guilty file from the repository history.  If it's a directory, it's
> even worse.  I had to do this myself with darcs, when I had two files named
> diff.lhs and Diff.lhs (you can still see, like fossils, mention of diff.lhs
> in Makefiles of old patches).

OK, let's say that files that existed once-upon-a-time in the repository
are called old files. Do old files still have an impact on the actual
files in a current repository? i.e. will an old file cause problems
because of files that actually exist in a current repository, or because
of problems that would only exist if someone tried to recreate the
earlier version of the repository that contained the old file?

If the problem is only that earlier versions of the repository would
cause problems, then it would still be possible for a user to do work on
a project without running into problems, so long as they didn't revert
to that earlier version.

If the problem is that the current version of the repository will still
have filename problems because of the old file, then I guess that's a
bigger problem.

Be well,
Zack

> 
> So the point is that I'll not just warn the users when they try to add
> weird filenames, but will disallow it unless they use an override flag (as
> currently --case-ok overrides the case-insensitive filename check).
> 
> As far as timeframe and how to implement arbitrary filenames, I think I
> have a good plan, which should fix the space issue and the unicode filename
> issue at one go.  The idea is to fix these problems when I switch Patches
> from using Strings to hold their filenames to using PackedStrings.  When I
> do this, I'll have to add conversion functions all over the place anyways,
> and I'll just use packFilePath and unpackFilePath, rather than packString
> and unpackPS, where (un)packFilePath will convert from(to) unicode to(from)
> utf8 and also will escape whitespace into nonwhitespace (e.g. ' ' -> "\\s"
> or something like that).  This will mean I don't have to change my parsing
> routines, which assume filenames are delimited by whitespace.
> -- 
> David Roundy
> http://www.abridgegame.org
> 
> _______________________________________________
> darcs-users mailing list
> darcs-users at abridgegame.org
> http://www.abridgegame.org/mailman/listinfo/darcs-users

-- 
Zack Brown




More information about the darcs-users mailing list