On 09/01/2008, Laurent Vivier <[EMAIL PROTECTED]> wrote: > Le mercredi 09 janvier 2008 à 13:27 +0000, Johannes Schindelin a écrit : > > Hi, > > > > On Wed, 9 Jan 2008, Laurent Vivier wrote: > > > > > Le mercredi 09 janvier 2008 à 12:27 +0000, Johannes Schindelin a écrit : > > > > > > > On Wed, 9 Jan 2008, Laurent Vivier wrote: > > > > > > > > > but "-hda" is an alias for "-drive file="%s",index=%d,media=disk". > > > > > > > > It appears to me as if "-hda" is implemented suboptimally, then. In > > > > particular, drive_add() should be able to get a separate "file" > > > > parameter, which can be overridden by the "fmt" parameter. Of course, > > > > this would mean that the global drives_opt[] array should not have > > > > element type "char", but a struct. > > > > > > This introduces complexity and special cases I don't want to manage... > > > > The problem is that you introduced a regression, as you can see by the > > size of this thread. > > The solution is very simple to restore original behavior: don't manage > filename with spaces.
The original -hda had no problems with spaces in filenames afaik? The trick in the original -hda syntax was that the path component was always last in the string (e.g. fat:rw:path), while in -drive there can be attributes after the path so you need a (single) character that has a special function. Currently there are five: space, comma, quote, backslash, equal. Regards
