On 3/16/2016 8:49 AM, Lester Caine wrote:
On 16/03/16 11:39, James Starkey wrote:
Or simply restrict database file names to ASCII. It's not like users
have to deal with them, just like they don't have to deal with
identifiers in SQL, or C or Java.
As someone linguistically challenged, I have n
On 16/03/16 11:39, James Starkey wrote:
> Or simply restrict database file names to ASCII. It's not like users
> have to deal with them, just like they don't have to deal with
> identifiers in SQL, or C or Java.
As someone linguistically challenged, I have no problem with my own
code, but English
On Wednesday, March 16, 2016, Lester Caine wrote:
> On 16/03/16 08:18, Александр Пешков wrote:
> > Could somebody explain why Firebird is in the filename translation
> > business at all?
> >
> > Imagine a system, containing linux server, using UTF-8 encoding, some
> > linux clients (also
On 16/03/16 08:18, Александр Пешков wrote:
> Could somebody explain why Firebird is in the filename translation
> business at all?
>
> Imagine a system, containing linux server, using UTF-8 encoding, some
> linux clients (also UTF-8) and some windows clients (cp1251, I use
> russian sampl
>22:06 +03:00 от Jim Starkey :
>
>Could somebody explain why Firebird is in the filename translation
>business at all?
Imagine a system, containing linux server, using UTF-8 encoding, some linux
clients (also UTF-8) and some windows clients (cp1251, I use russian sample)
and using russian name
Could somebody explain why Firebird is in the filename translation
business at all? Other than the need for the inet remote interface to
follow symbolic links, historically this has not been necessary. It
clearly isn't needed to open the file.
If the purpose is to server as the root of the loc
On 15/03/2016 13:30, Dimitry Sibiryakov wrote:
> 15.03.2016 13:24, Adriano dos Santos Fernandes wrote:
>> Also should test old client (which cannot use utf8_filename dpb)
>> connecting to new (with your change, and already one without it)
>> checking it work as originally.
>Old client that does
15.03.2016 13:24, Adriano dos Santos Fernandes wrote:
> Also should test old client (which cannot use utf8_filename dpb)
> connecting to new (with your change, and already one without it)
> checking it work as originally.
Old client that doesn't support utf8_filename flag is 2.1. Is Firebird
v
15.03.2016 14:50, Michal Kubecek wrote:
> As most linux distributions have been using UTF-8 for everything for
> quite some time, file names ended up being in UTF-8 as well. But it's
> just kind of an "unwritten law", not a standard.
Ok, I'll add calls to Utf8ToSystem into unix.cpp before fopen
On Tue, Mar 15, 2016 at 01:49:20PM +0100, Dimitry Sibiryakov wrote:
> >Does POSIX requires any changes for this issue ?
>
>AFAIK - no, fopen() handles utf-8 in file names out of box.
I would rather say posix filesystems are encoding agnostic. In general,
the file name is just a sequence o
15.03.2016 14:00, Alex Peshkoff wrote:
> Please provide proof reference for it.
http://stackoverflow.com/questions/4676327/how-to-open-a-file-with-wchar-t-containing-non-ascii-string-in-linux
--
WBR, SD.
--
Transform
On 03/15/2016 03:49 PM, Dimitry Sibiryakov wrote:
> 15.03.2016 13:36, Vlad Khorsun wrote:
>> But why you not included it into namespace os_utils ???
> To keep old code working. Otherwise I would have to change every piece of
> code where
> the class is used.
It's OS specific and therefore bel
On 03/15/2016 03:36 PM, Vlad Khorsun wrote:
>> Question: should I commit them at once or separately?
> I see two questions in statement above.
I've discussed some points with author privately in russian and I do not
agree with this commit. It's half done and breaks a lot of places even
15.03.2016 13:47, Adriano dos Santos Fernandes wrote:
> No regressions in any commit is top priority.
Sure. I'll do extended testing in areas you mentioned.
> It surely work.
>
> Without isc_dbp_utf8_filename ever work as intended. You sure should
> test this with different servers and clients
15.03.2016 13:36, Vlad Khorsun wrote:
> But why you not included it into namespace os_utils ???
To keep old code working. Otherwise I would have to change every piece of
code where
the class is used.
Besides, I doubt that this all-purpose class belongs to that namespace.
> Also, i prefer
On 15/03/2016 09:41, Dimitry Sibiryakov wrote:
> 15.03.2016 13:24, Adriano dos Santos Fernandes wrote:
>> You should at least test every code path related to the functions you
>> changed the input/output code page, like code paths related to files
>> names in databases (external files, shadows, wha
15.03.2016 13:24, Adriano dos Santos Fernandes wrote:
> You should at least test every code path related to the functions you
> changed the input/output code page, like code paths related to files
> names in databases (external files, shadows, whatever).
I was explicitly asked by admins not to
15.03.2016 14:05, Dimitry Sibiryakov wrote:
>In attachment you can find patch for CORE-3172 and another one that adds
> minimal support for unicode database names into engine.
You moved class WideCharBuffer into os_utils, as suggested, it is ok.
But why you not included it into namespace o
On 15/03/2016 09:18, Dimitry Sibiryakov wrote:
> 15.03.2016 13:13, Alex Peshkoff wrote:
>> first of all I
>> want to know how was it tested - what environments and what tasks.
>Testcase was attached. Only operations relevant to CORE-3172 were tested:
> creation of
> database and attach. The
On 03/15/2016 03:18 PM, Dimitry Sibiryakov wrote:
> 15.03.2016 13:13, Alex Peshkoff wrote:
>>first of all I
>> want to know how was it tested - what environments and what tasks.
> Testcase was attached. Only operations relevant to CORE-3172 were tested:
> creation of
> database and attach.
15.03.2016 13:13, Alex Peshkoff wrote:
> first of all I
> want to know how was it tested - what environments and what tasks.
Testcase was attached. Only operations relevant to CORE-3172 were tested:
creation of
database and attach. The rest is untouched by patch and will require separate
t
On 03/15/2016 03:05 PM, Dimitry Sibiryakov wrote:
> 14.03.2016 9:49, Dimitry Sibiryakov wrote:
>>Agreement?
>
> Silence is an agreement, huh?..
>
> In attachment you can find patch for CORE-3172 and another one that
> adds minimal support for unicode database names into engine. Together
>
14.03.2016 9:49, Dimitry Sibiryakov wrote:
Agreement?
Silence is an agreement, huh?..
In attachment you can find patch for CORE-3172 and another one that adds minimal
support for unicode database names into engine. Together they make attached testcase work.
These patches target only
14.03.2016 20:34, Leyne, Sean wrote:
> Alex,
>
>> Sean, if we limit ourself to only already opened files - we have no problems.
>> But there are places (like per-database config) where we are not sure does
>> file exist and if yes is it opened or not. For posix (where file ID exists no
>> matter is
;For discussion among Firebird Developers"
Onderwerp: [Firebird-devel] RFC: File names with non-ASCII non-ANSI letters
Datum: ma, mrt. 14, 2016 19:43
14.03.2016 19:25, Lester Caine wrote:
> This is Microsoft you are dealing with ... what do you expect?
I can guess that using LCMapString
14.03.2016 19:25, Lester Caine wrote:
> This is Microsoft you are dealing with ... what do you expect?
I can guess that using LCMapStringW(LOCALE_INVARIANT) may produce result
matching to
NTFS UpCase transformation in most cases, but I wouldn't bet my dinner on it.
--
WBR, SD.
-
Alex,
> Sean, if we limit ourself to only already opened files - we have no problems.
> But there are places (like per-database config) where we are not sure does
> file exist and if yes is it opened or not. For posix (where file ID exists no
> matter is file opened or not) I'm currently using fas
On 14/03/16 17:57, Adriano dos Santos Fernandes wrote:
> On 14/03/2016 14:52, Dimitry Sibiryakov wrote:
>> > 14.03.2016 18:32, Adriano dos Santos Fernandes wrote:
>>> >> Proofs, please. Not guesses.
>> > http://blogs.msdn.com/b/michkap/archive/2005/01/16/353873.aspx
>> >
>> >
> A site that I need t
On 14/03/2016 14:52, Dimitry Sibiryakov wrote:
> 14.03.2016 18:32, Adriano dos Santos Fernandes wrote:
>> Proofs, please. Not guesses.
> http://blogs.msdn.com/b/michkap/archive/2005/01/16/353873.aspx
>
>
A site that I need to authenticate, fill forms, agree with whatever and
in the end says the pag
14.03.2016 18:32, Adriano dos Santos Fernandes wrote:
> Proofs, please. Not guesses.
http://blogs.msdn.com/b/michkap/archive/2005/01/16/353873.aspx
Russian translation:
http://www.transl-gunsmoker.ru/2010/07/how-case-insensitive.html
--
WBR, SD.
On 14/03/2016 05:49, Dimitry Sibiryakov wrote:
> It is not widely known, but NTFS has
> its own upcase table that may be different from system one. In this case
> uppercasing of the name using system locale will cause file to be not
> found
Proofs, please. Not guesses.
Adriano
On 03/14/2016 07:39 PM, Leyne, Sean wrote:
> Alex,
>
>> The main problem with use of any kind of file ID is when create database is
>> performed - file may not exist.
> What kind of "use" of the file ID are you referring to?
>
> AFAIU, the file ID would only be used to identify if a db filename ma
Alex,
> The main problem with use of any kind of file ID is when create database is
> performed - file may not exist.
What kind of "use" of the file ID are you referring to?
AFAIU, the file ID would only be used to identify if a db filename matches an
existing/already opened db file (the file
14.03.2016 9:53, Alex Peshkoff wrote:
> Not deadlock. Just races. And not too critical.
>
> The main problem with use of any kind of file ID is when create database
> is performed - file may not exist.
Both these problems can be easily solved with already existing mutexes and
careful
planning
On 03/12/2016 01:07 PM, Dimitry Sibiryakov wrote:
> 11.03.2016 23:21, Leyne, Sean wrote:
>> why are we "munging" the filename string to determine unique files?
> Didn't you read? Alex tried to but failed and got deadlocks.
>
Not deadlock. Just races. And not too critical.
The main problem wit
Final edition:
1) File name from connection string is converted into UTF-8 ASAP.
No code should ever convert it into ANSI codepage.
2) Windows version uses Unicode routines for file handling.
3) File names are not uppercased. It is not widely known, but NTFS has
its own upcase table that may be di
11.03.2016 23:21, Leyne, Sean wrote:
> why are we "munging" the filename string to determine unique files?
Didn't you read? Alex tried to but failed and got deadlocks.
--
WBR, SD.
--
Transform Data into Opportunit
> >> Why it is better than BY_HANDLE_FILE_INFORMATION used currently ?
> >
> > FILE_OBJECTID_BUFFER has a unique File/Object ID,
> BY_HANDLE_FILE_INFORMATION doesn't provide such a value.
>
> {dwVolumeSerialNumber, nFileIndexHigh, nFileIndexLow} is a unique
> combination.
I stand corrected, I m
On 11/03/16 16:53, Leyne, Sean wrote:
> The user would be able to name the database anything they want, they would
> simply need to have the same name.
The problem with that statement is something that caught me out a while
back hence asking about the current state of Windows. When moving from
wi
11.03.2016 23:26, Leyne, Sean wrote:
>
>> Why it is better than BY_HANDLE_FILE_INFORMATION used currently ?
>
> FILE_OBJECTID_BUFFER has a unique File/Object ID, BY_HANDLE_FILE_INFORMATION
> doesn't provide such a value.
{dwVolumeSerialNumber, nFileIndexHigh, nFileIndexLow} is a unique
combinati
> > It seems that no one has looked at the File Management Structures of
> > the Windows API for quite some time, it seems that ObjectId of the
> > FILE_OBJECTID_BUFFER structure (which is supported as of WinXP) would
> also seem to fit the bill!
>
>Why it is better than BY_HANDLE_FILE_INFOR
11.03.2016 18:33, Leyne, Sean wrote:
> It seems that no one has looked at the File Management Structures of the
> Windows API for quite some time,
> it seems that ObjectId of the FILE_OBJECTID_BUFFER structure (which is
> supported as of WinXP) would also
> seem to fit the bill!
Why it is be
On 03/11/2016 07:36 PM, Dimitry Sibiryakov wrote:
> 11.03.2016 17:25, Alex Peshkoff wrote:
>> I've already answered that
> No, you said that unique id does not exist on Windows, which is not true.
To be precise - persistent file if, existing after file is closed, does
not exist for windows. T
> Sean, I see no problems with changing way of files comparison for windows if
> needed. I just disagree with case-insensitive comparison on posix where FS is
> case-sensitive.
> And it applies to all places where file names are used, including config
> files.
Then maybe we need to rethink how
On 03/11/2016 07:33 PM, Leyne, Sean wrote:
> Alex,
>
>> OS certainly knows, but when we attach to database SAMPLE.fdb we look in
>> the list of opened databases - do we already have such database opened?
>> And if we use case-insensitive comparison of file names and have sample.fdb
>> already attac
11.03.2016 17:25, Alex Peshkoff wrote:
> I've already answered that
No, you said that unique id does not exist on Windows, which is not true.
And you said
that thread races are solved with looking by name instead of proper
serialization of dbb
list access.
--
WBR, SD.
Alex,
> OS certainly knows, but when we attach to database SAMPLE.fdb we look in
> the list of opened databases - do we already have such database opened?
> And if we use case-insensitive comparison of file names and have sample.fdb
> already attached we will decide that we have one more attachmen
On 03/11/2016 07:19 PM, Dimitry Sibiryakov wrote:
> 11.03.2016 17:15, Alex Peshkoff wrote:
The OS knowns if the file is the same or not, regardless of the case
spelling...
>> OS certainly knows, but when we attach to database SAMPLE.fdb we look in
>> the list of opened databases - do we
11.03.2016 17:15, Alex Peshkoff wrote:
>> >The OS knowns if the file is the same or not, regardless of the case
>> >spelling...
> OS certainly knows, but when we attach to database SAMPLE.fdb we look in
> the list of opened databases - do we already have such database opened?
We can open the f
On 03/11/2016 06:59 PM, Leyne, Sean wrote:
>
>> When 2 different files will be opened as same dbb in SS that will be
>> definitely
>> not very convenient.
> But couldn't that be addressed by having SS open database files using
> "Exclusive Read/Write" access, instead of "Shared Read/Write" needed
On 11/03/2016 08:03, Dimitry Sibiryakov wrote:
>Unfortunately, most of text editors (including Notepad) by default save
> files in ANSI
> encoding.
Yes, because that is the "Windows standard" for users.
Don't make things difficult for users.
If admin installed a Windows with some locale, i
> When 2 different files will be opened as same dbb in SS that will be
> definitely
> not very convenient.
But couldn't that be addressed by having SS open database files using
"Exclusive Read/Write" access, instead of "Shared Read/Write" needed by Classic?
The OS knowns if the file is the sa
On 11/03/16 12:07, Dimitry Sibiryakov wrote:
>> The fact that windows does not currently support UTF8 for file names is
>> > the problem here?
>Windows fully support UTF-16. Firebird doesn't.
I'm not sure that I agree with that. Certainly as Mark says it's the
switch to windows UTF-16 transcod
On Fri, Mar 11, 2016 at 12:16:38PM +0100, Dimitry Sibiryakov wrote:
> 11.03.2016 12:12, Michal Kubecek wrote:
> > If so, I'm not an advanced user. I certainly don't know which of the
> > many text utilities would preserve BOM.
>
>Don't worry, Notepad always save UTF-8 files with BOM.
Ah, I ac
On 03/11/2016 02:49 PM, Dimitry Sibiryakov wrote:
> 11.03.2016 12:43, Alex Peshkoff wrote:
>> On 03/11/2016 02:28 PM, Dimitry Sibiryakov wrote:
11.03.2016 12:19, Alex Peshkoff wrote:
>> When 2 different files will be opened as same dbb in SS that will be
>> definitely not very convenie
On 2016-03-11 13:07, Mark Rotteveel wrote:
> On 2016-03-11 12:58, Dimitry Sibiryakov wrote:
>> 11.03.2016 12:52, Mark Rotteveel wrote:
>>> No, everything should be UTF-8, no excuses, no exceptions.
>>
>>This is my desire as well. But I still have no will to explain to
>> every fool where to
>>
On 2016-03-11 13:02, Lester Caine wrote:
> On 11/03/16 11:49, Dimitry Sibiryakov wrote:
>> 11.03.2016 12:43, Alex Peshkoff wrote:
>>> > On 03/11/2016 02:28 PM, Dimitry Sibiryakov wrote:
> >> >11.03.2016 12:19, Alex Peshkoff wrote:
>>> >>> >>When 2 different files will be opened as same dbb
11.03.2016 13:02, Lester Caine wrote:
> The fact that windows does not currently support UTF8 for file names is
> the problem here?
Windows fully support UTF-16. Firebird doesn't.
--
WBR, SD.
--
Transform Data int
On 2016-03-11 12:58, Dimitry Sibiryakov wrote:
> 11.03.2016 12:52, Mark Rotteveel wrote:
>> No, everything should be UTF-8, no excuses, no exceptions.
>
>This is my desire as well. But I still have no will to explain to
> every fool where to
> find combo box to switch encoding. As I already sai
On 11/03/16 11:49, Dimitry Sibiryakov wrote:
> 11.03.2016 12:43, Alex Peshkoff wrote:
>> > On 03/11/2016 02:28 PM, Dimitry Sibiryakov wrote:
>> >11.03.2016 12:19, Alex Peshkoff wrote:
>> >>> >>When 2 different files will be opened as same dbb in SS that will
>> >>> >>be
>> >>> >>d
11.03.2016 12:52, Mark Rotteveel wrote:
> No, everything should be UTF-8, no excuses, no exceptions.
This is my desire as well. But I still have no will to explain to every fool
where to
find combo box to switch encoding. As I already said, Windows Notepad has ANSI
set there
by default.
--
On 2016-03-11 12:03, Dimitry Sibiryakov wrote:
> 11.03.2016 11:56, Mark Rotteveel wrote:
>> Please, use UTF-8 for these files (without BOM, BOM is discouraged
>> for
>> UTF-8).
>
>Yes, it is discouraged, but it is the only reliable way to detect
> file encoding
> automatically.
Except that it
11.03.2016 12:43, Alex Peshkoff wrote:
> On 03/11/2016 02:28 PM, Dimitry Sibiryakov wrote:
>> >11.03.2016 12:19, Alex Peshkoff wrote:
>>> >>When 2 different files will be opened as same dbb in SS that will be
>>> >>definitely not very convenient.
>> > SS rely on file name when is looking if dat
On 03/11/2016 02:28 PM, Dimitry Sibiryakov wrote:
> 11.03.2016 12:19, Alex Peshkoff wrote:
>> When 2 different files will be opened as same dbb in SS that will be
>> definitely not very convenient.
> SS rely on file name when is looking if database is already opened?
Currently yes. The main re
11.03.2016 12:19, Alex Peshkoff wrote:
> When 2 different files will be opened as same dbb in SS that will be
> definitely not very convenient.
SS rely on file name when is looking if database is already opened? Inode
would be more
robust...
--
WBR, SD.
-
On 03/11/2016 02:07 PM, Dimitry Sibiryakov wrote:
> 11.03.2016 12:03, Alex Peshkoff wrote:
>> For posix case-sensitive routines must be used.
> Are you sure?
Absolutely.
> It is more a matter of convenience for users, not FS rules.
>
When 2 different files will be opened as same dbb in SS th
11.03.2016 12:12, Michal Kubecek wrote:
> If so, I'm not an advanced user. I certainly don't know which of the
> many text utilities would preserve BOM.
Don't worry, Notepad always save UTF-8 files with BOM.
> Also, I'm pretty sure I would keep forgetting even if I knew. And that
> there would
On Fri, Mar 11, 2016 at 12:03:41PM +0100, Dimitry Sibiryakov wrote:
> 11.03.2016 11:56, Mark Rotteveel wrote:
> > Please, use UTF-8 for these files (without BOM, BOM is discouraged for
> > UTF-8).
>
> Yes, it is discouraged, but it is the only reliable way to detect file
> encoding automatically.
11.03.2016 12:03, Alex Peshkoff wrote:
> For posix case-sensitive routines must be used.
Are you sure? It is more a matter of convenience for users, not FS rules.
--
WBR, SD.
--
Transform Data into Opportunity.
Ac
On 03/11/2016 01:51 PM, Dimitry Sibiryakov wrote:
> 5) Case-insensitive
For posix case-sensitive routines must be used.
> routines are used for comparsion of file names from connection string
> and configs. They can use system locale.
>
> Comments?..
>
-
11.03.2016 11:56, Mark Rotteveel wrote:
> Please, use UTF-8 for these files (without BOM, BOM is discouraged for
> UTF-8).
Yes, it is discouraged, but it is the only reliable way to detect file
encoding
automatically.
Unfortunately, most of text editors (including Notepad) by default save
On 2016-03-11 11:51, Dimitry Sibiryakov wrote:
> 4) Databases.conf (and other configs) are considered to have ANSI
> codepage unless they
> have BOM. File names and pathes in config are converted into UTF-8 or
> UTF-16 on read.
Please, use UTF-8 for these files (without BOM, BOM is discouraged fo
Hello, All.
We have in tracker multiple tickets about problems with non-ASII names for
database
files. Some of them: CORE-4993, CORE-316 (fixed incorrectly), CORE-2172,
CORE-3172 (which
is not duplicate and is caused by different reason).
I suggest to set it up finally in this way:
1
73 matches
Mail list logo
