With some remorse, I recently realized that the PathName class and file name matching is my fault as is the larger problem of a client identifying a database by filename. It has never worked well, and if pushed, works badly. File names are excellent for opening files and bad almost anything else. They are syntactically platform dependent and subject to all sorts of underhanded tricks like embedded node names with punctuation used to identify node names. And worst, because of the possibility of hard links, there is not and cannot be a canonical representation of any given file.
If should be clear that if in the dozen-plus years since Vulcan the kinks haven't been worked out, the kinks probably can't. The saving grace here is that the interface doesn't specify database file name, just a connection string that the various providers can have a go at. Lots of wiggle room here. I suggest that FB4 get completely out of the business of passing database file names over the API and go strictly with something like a URL that identifies the location and name of a database, letting the server configuration map the name into a file name, et al. Probably most of the code is already there and functional, so the exercise should be more dropping the interpretation of connection string as file name, aided by a client side back to map legacy connection strings into URLs.. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
