monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Changes in nvm.basic_io.inventory


From: Zack Weinberg
Subject: Re: [Monotone-devel] Changes in nvm.basic_io.inventory
Date: Sun, 22 Jul 2007 17:41:20 -0700

On 7/22/07, address@hidden <address@hidden> wrote:
On Mon, Jul 23, 2007 at 12:59:21AM +0200, Thomas Keller wrote:
> I'm currently skimming over the bug reports wrt automate inventory of
> the last months (this [0] is a good starting point) and stumbled across
> another:
>
> https://savannah.nongnu.org/bugs/?17361
>
> Since monotone will never - and any other cross-platform software
> neither - get proper support for any special file type

special file *type*?  This bug refers to files with weird characters in
the names.  I was worried for a moment.  I thought you meant that
monotone would, for example, never acquire proper merge semantics for
XML files (whatever that might be!)

Actually, there's nothing wrong with the name; the problem is that the
filesystem entity associated with that name is neither a file nor a
directory.  Monotone currently refuses to work with such things at a
very low level (the directory reading function in unix/fs.cc).  We
could, and should, do a lot better; for instance, as this bug report
suggests, if they're in .mtn-ignore we should just ignore them.  I
believe someone had a patch that was a first step toward that, leaving
it up to the directory scanner's caller to do something sensible or
reject...

(It should be mentioned, though, that we have to be very very careful
with non-file, non-directory objects.  Even calling open() on one can
have nasty consequences, such as blocking monotone until an external
event that may never occur, or screwing up the operation of unrelated
processes on the same computer.  This is why we reject them on sight;
it's pure defensiveness.)

zw




reply via email to

[Prev in Thread] Current Thread [Next in Thread]