Re[2]: [Firebird-devel] More filenames (I'm sorry, I really am)

[Nando D. <na...@de...>]

Paul,

>> PR> It is arguable that .gbak describes a file to be used with gbak.
>> PR>  If we want .fbak we should perhaps consider changing gbak to fbak (and gfix to
>> PR> ffix etc.) Personally, I think I'd rather leave gbak as gbak.
>> 
>> on the other hand, changing the names would fully deliver the benefit
>> of coexistence with InterBase.

PR> Yes - and break the assumptions of lots of applications (such as batch 
PR> files, cron jobs) that assume gbak, gfix etc. Is it worth it?

MHO: it is worthwhile, advisable and mandatory. :-)

those same applications assume that the client is called gds32.dll,
which hasn't stopped us from changing it to a more meaningful name.
The fact that I propose changing the names does not imply that I am
against a compatibility layer. Actually I would welcome it, for
compatibility reason, but I think a "clean" Firebird installation
(i.e. one that needn't to coexist with IB) should be free from "G"'s and "IB"'s.

You also wrote:

PR> The original
PR> argument from Nando was that changing the naming convention better helps 
PR> to have Firebird and InterBase installed on the same machine.

True.

PR> The main
PR> reason for that, I would suppose, is that applications could use either 
PR> server transaparently.

That's not my main concern; actually, I regard this kind of
"transparency" as more dangerous than useful. The main reason for the
proposal to change name is quite the opposite: avoiding calling Firebird's
gbak for mistake when I intended to call IB's gbak, and vice-versa. I
think it's very common to add the Bin directory to the system search
path, and I would like to be able to install a Firebird client
without messing up an existing InterBase installation, scripts & all.

If one needs to *port* his existing IB scripts & tools to Firebird, then a
symlink, rename or Firebird-provided compatibility stub, just like
it's done for the client library, will do.

>> I'm not sure if Windows' shortcuts can do the same.
>> 
PR> 
PR> I don't believe they can. MS have made some attempts in that direction 
PR> but there is still nothing quite so simple as a symlink under Win32.

I used to symlink in W2K all the time, I haven't tried with my current
WXP. I think I installed a little additional tool from a Resource Kit
CD in W2K to allow for that, and I seem to recall that it used a
feature of NTFS called junction points or something like that. I can
be more specific once I get near a W2K box if anyone's interested.
Ciao
-- 
Nando                            mailto:na...@de...