Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-09 Thread Björn Reimer
Hello,

 
>>> True, but what device?  What path?

>> Well, a good question. In this case at a customers server more than one temp 
>> path was configured to avoid this situation.

> What Firebird version? Might be related to:
> http://tracker.firebirdsql.org/browse/CORE-3757


Good point. I'll check next time I'm on the customers server.


Björn

-- 
Björn Reimer - RRZE


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-06 Thread Mark Rotteveel
On 4-10-2012 20:57, Vlad Khorsun wrote:
>> Why does Firebird return such a low level OS-dependent(?) error message
>> instead of returning a Firebird-specific message that explains what went
>> wrong (eg creating temporary files), instead of why it failed (the
>> low-level error message)?
>
> - because it was written this way many years ago (before it became Firebird)
> - because without original lowest-level error it is impossible to find a 
> reason for failure
> - because in most cases it is obvious what Firebird did at failure moment
>
>  I agree that sometime more context from intermediate levels could help 
> to better
> understand what happens. For example, when transliterate error happens it is 
> good
> to know assignment destination (field or variable) name. I'm not sure it is 
> easy to
> implement. But in the case of "CreateFile failed" when index is built... - i 
> see nothing
> to add here, it is clear enough as for me...

I don't: as an 'end-user' of Firebird I have no clue what it means, in 
this case it is not that bad because you also have the message "cannot 
commit index IDX_RMGM_IMPORT_DNA", although an additional explanation 
like "failed to create temporary file" or something would be helpful.

It is worse in other situations: eg trying to connect to a database, or 
creating a new database. This is the message you get when trying to 
connect to a non-existent database on Windows (with flamerobin):

*** IBPP::SQLException ***
Context: Database::Connect
Message: isc_attach_database failed

SQL Message : -902
Unsuccessful execution caused by a system error that precludes 
successful execution of subsequent statements

Engine Code: 335544344
Engine Message :
I/O error during "CreateFile (open)" operation for file "D:\XYZ.FDB"
Error while trying to open file
Het systeem kan het opgegeven bestand niet vinden.

(The system cannot find the specified file.)
The first time I was confronted with this error message, I thought 
"What, why is it trying to create a file, the database already exists?"

On Linux I get
Engine Code: 335544344
Engine Message :
I/O error during "open" operation for file "/opt/xyz.fdb"
Error while trying to open file
No such file or directory

"Huh, a a similar, but different error message?"

Now on a DVD-ROM drive that does not contain a disk:

Engine Code: 335544344
Engine Message :
I/O error during "CreateFile (open)" operation for file "F:\XYZ\XYZ.FDB"
Error while trying to open file
Het apparaat is niet klaar.

(Device is not ready)
Now what happens if I try to connect to the same non-existent database 
with DatabaseAccess = Restrict D:\data\DB:

Engine Code: 335544831
Engine Message :
Access to database "D:\XYZ.FDB" is denied by server administrator

What would happen when I try to connect to a drive that does not exist 
(eg: drive K:\) (Note: same with or without DatabaseAccess restriction)

SQL Message : -904
Unsuccessful execution caused by an unavailable resource.

Engine Code: 335544375
Engine Message :
unavailable database

Now with a file that the user has no access to (eg read access is denied 
in the ACL):

Engine Code: 335544344
Engine Message :
I/O error during "CreateFile (open)" operation for file 
"D:\DATA\DB\TESTDATABASE.FDB"
Error while trying to open file
Toegang geweigerd.

(Access denied)
Firebird is leaking information about the layout of a computer (eg 
existence or non-existence of drives), and about the security 
configuration of both Firebird (DatabaseAccess) and the rights 
configuration on file or folder level.

I would expect and prefer that in all these cases that the error message 
would be the same (eg: "Unable to attach to database '': Database 
does not exist or is not accessible", where  is the original alias 
or path used in the connection string, and not the actual path Firebird 
tries).
The actual error details would then be logged in firebird.log. 
Interestingly, of the above attempts to access a non-existent or 
restricted file, nothing(!) is logged in firebird.log.

Mark
-- 
Mark Rotteveel

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Thomas Steinmaurer
 I agree that sometime more context from intermediate levels could
 help to better understand what happens. For example, when transliterate
 error happens it is good to know assignment destination (field or
 variable) name. I'm not sure it is easy to implement. But in the case
 of "CreateFile failed" when index is built... - i see nothing to add here, 
 it is
>>> clear enough as for me...
>
>>> The OS message in this case should be helpful enough:
>>> "gbak: ERROR:Das Gerät ist nicht bereit.
>
>>> (Device is not ready) suggests it's a problem the administrator has to deal
>>> with as Firebird doesn't control OS level stuff like file permissions, 
>>> mounting
>>> devices, making sufficient temp space available, et al.
>
>> True, but what device?  What path?
>
> Well, a good question. In this case at a customers server more than one temp 
> path was configured to avoid this situation.

What Firebird version? Might be related to:
http://tracker.firebirdsql.org/browse/CORE-3757


Regards,
Thomas

> And: There was much free space on the device (More than 10 GB for a 2 GB 
> database. The index should have been created on a table of about 3.5 Mio 
> records.)
>
> So I think my customer has a problem with his raid system.
>
>> The current message is 99% useless without the file path/name.  It 
>> effectively reads as:
>
>> "You have a problem... somewhere.  Go figure it out."
>
> Yes and one more:
>
> There was no hint at the end of restore process that an error occurred. I'd 
> expect a printed message. I don't know wether an exit level was returned or 
> something like that.
>
>
>
>
>>> But maybe Bjoern's point has been missed:  why should a temp file be
>>> needed to restore deactivated indexes?
>
>> I don't think that was his point, but will see what he says.
>
> No, that's obvious that firebird needs temp space for index creation if there 
> are some more records involved.
>
>
> Björn
>


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Björn Reimer



>> >I agree that sometime more context from intermediate levels could
>> >help to better understand what happens. For example, when transliterate
>> >error happens it is good to know assignment destination (field or
>> >variable) name. I'm not sure it is easy to implement. But in the case
>> >of "CreateFile failed" when index is built... - i see nothing to add here, 
>> >it is
>> clear enough as for me...

>> The OS message in this case should be helpful enough:
>> "gbak: ERROR:Das Gerät ist nicht bereit.

>> (Device is not ready) suggests it's a problem the administrator has to deal
>> with as Firebird doesn't control OS level stuff like file permissions, 
>> mounting
>> devices, making sufficient temp space available, et al.

> True, but what device?  What path?

Well, a good question. In this case at a customers server more than one temp 
path was configured to avoid this situation. 

And: There was much free space on the device (More than 10 GB for a 2 GB 
database. The index should have been created on a table of about 3.5 Mio 
records.) 

So I think my customer has a problem with his raid system.

> The current message is 99% useless without the file path/name.  It 
> effectively reads as:

> "You have a problem... somewhere.  Go figure it out."

Yes and one more:

There was no hint at the end of restore process that an error occurred. I'd 
expect a printed message. I don't know wether an exit level was returned or 
something like that.




>> But maybe Bjoern's point has been missed:  why should a temp file be
>> needed to restore deactivated indexes?

> I don't think that was his point, but will see what he says.

No, that's obvious that firebird needs temp space for index creation if there 
are some more records involved.


Björn

-- 
Björn Reimer - RRZE


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Vlad Khorsun
>>>I agree that sometime more context from intermediate levels could
>>>help to better understand what happens. For example, when transliterate
>>>error happens it is good to know assignment destination (field or
>>>variable) name. I'm not sure it is easy to implement. But in the case
>>>of "CreateFile failed" when index is built... - i see nothing to add here, 
>>>it is
>> clear enough as for me...
>>
>> The OS message in this case should be helpful enough:
>> "gbak: ERROR:Das Gerät ist nicht bereit.
>>
>> (Device is not ready) suggests it's a problem the administrator has to deal
>> with as Firebird doesn't control OS level stuff like file permissions, 
>> mounting
>> devices, making sufficient temp space available, et al.

Looks like famous "printer is out of paper" Windows error :) But we can't 
control
OS errors, all we can do - is to catch and report it. If we did it wrong i need 
reproducible
test case to be able to investigate it.

> True, but what device?  What path?

DBA should know where temporary files is placed. If my memory serves me 
well, this
issue was discussed few years ago and it was decided to not include full file 
names in
such error messages from the security POV...

> The current message is 99% useless without the file path/name.  It 
> effectively reads as:
>
> "You have a problem... somewhere.  Go figure it out."

This particular case is clear. Other cases could be less clear, agree.

Regards,
Vlad 


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Leyne, Sean


> >I agree that sometime more context from intermediate levels could
> >help to better understand what happens. For example, when transliterate
> >error happens it is good to know assignment destination (field or
> >variable) name. I'm not sure it is easy to implement. But in the case
> >of "CreateFile failed" when index is built... - i see nothing to add here, 
> >it is
> clear enough as for me...
> 
> The OS message in this case should be helpful enough:
> "gbak: ERROR:Das Gerät ist nicht bereit.
> 
> (Device is not ready) suggests it's a problem the administrator has to deal
> with as Firebird doesn't control OS level stuff like file permissions, 
> mounting
> devices, making sufficient temp space available, et al.

True, but what device?  What path?

The current message is 99% useless without the file path/name.  It effectively 
reads as:

"You have a problem... somewhere.  Go figure it out."


> But maybe Bjoern's point has been missed:  why should a temp file be
> needed to restore deactivated indexes?

I don't think that was his point, but will see what he says.


> Could that be a bug whereby, at the point where gbak is creating the deferred 
> indexes, it has lost
> the significance of the original "inactive" flag?


Huh?


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Helen Borrie
At 07:57 AM 5/10/2012, Vlad Khorsun wrote:

>> Why does Firebird return such a low level OS-dependent(?) error message
>> instead of returning a Firebird-specific message that explains what went
>> wrong (eg creating temporary files), instead of why it failed (the
>> low-level error message)?
>
>- because it was written this way many years ago (before it became Firebird)
>- because without original lowest-level error it is impossible to find a 
>reason for failure
>- because in most cases it is obvious what Firebird did at failure moment
>
>I agree that sometime more context from intermediate levels could help to 
> better
>understand what happens. For example, when transliterate error happens it is 
>good
>to know assignment destination (field or variable) name. I'm not sure it is 
>easy to
>implement. But in the case of "CreateFile failed" when index is built... - i 
>see nothing
>to add here, it is clear enough as for me...

The OS message in this case should be helpful enough:
"gbak: ERROR:Das Gerät ist nicht bereit.  

(Device is not ready) suggests it's a problem the administrator has to deal 
with as Firebird doesn't control OS level stuff like file permissions, mounting 
devices, making sufficient temp space available, et al.

But maybe Bjoern's point has been missed:  why should a temp file be needed to 
restore deactivated indexes?  Could that be a bug whereby, at the point where 
gbak is creating the deferred indexes, it has lost the significance of the 
original "inactive" flag?

Helen


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Vlad Khorsun
> On 4-10-2012 19:30, Vlad Khorsun wrote:
>>>I don't know wether it has something to do with CORE-3940, but
>>
>> ...
>>>  gbak:activating and creating deferred index IDX_RMGM_IMPORT_DNA
>>> gbak:cannot commit index IDX_RMGM_IMPORT_DNA
>>>  gbak: ERROR:operating system directive CreateFile failed
>>>  gbak: ERROR:Das Gerät ist nicht bereit.
>>
>>
>>   i see no relation with CORE-3940
>>
>>  ...
>>>  Am I right that the CreateFile was when firebird tries to create temporary 
>>> files?
>>
>>   Sooner of all - yes

> Why does Firebird return such a low level OS-dependent(?) error message
> instead of returning a Firebird-specific message that explains what went
> wrong (eg creating temporary files), instead of why it failed (the
> low-level error message)?

- because it was written this way many years ago (before it became Firebird)
- because without original lowest-level error it is impossible to find a reason 
for failure
- because in most cases it is obvious what Firebird did at failure moment

I agree that sometime more context from intermediate levels could help to 
better
understand what happens. For example, when transliterate error happens it is 
good
to know assignment destination (field or variable) name. I'm not sure it is 
easy to
implement. But in the case of "CreateFile failed" when index is built... - i 
see nothing
to add here, it is clear enough as for me...

Regards,
Vlad


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Mark Rotteveel
On 4-10-2012 19:30, Vlad Khorsun wrote:
>>I don't know wether it has something to do with CORE-3940, but
>
> ...
>> gbak:activating and creating deferred index IDX_RMGM_IMPORT_DNA
>> gbak:cannot commit index IDX_RMGM_IMPORT_DNA
>> gbak: ERROR:operating system directive CreateFile failed
>> gbak: ERROR:Das Gerät ist nicht bereit.
>
>
>  i see no relation with CORE-3940
>
> ...
>> Am I right that the CreateFile was when firebird tries to create temporary 
>> files?
>
>  Sooner of all - yes

Why does Firebird return such a low level OS-dependent(?) error message 
instead of returning a Firebird-specific message that explains what went 
wrong (eg creating temporary files), instead of why it failed (the 
low-level error message)?

Mark

-- 
Mark Rotteveel

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Vlad Khorsun
>   I don't know wether it has something to do with CORE-3940, but

...
> gbak:activating and creating deferred index IDX_RMGM_IMPORT_DNA
> gbak:cannot commit index IDX_RMGM_IMPORT_DNA
> gbak: ERROR:operating system directive CreateFile failed
> gbak: ERROR:Das Gerät ist nicht bereit.


i see no relation with CORE-3940

...
> Am I right that the CreateFile was when firebird tries to create temporary 
> files?

Sooner of all - yes

Regards,
Vlad 


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] ERROR:operating system directive CreateFile failed

2012-10-04 Thread Leyne, Sean


>   I don't know wether it has something to do with CORE-3940, but
> 
> [...]
> gbak:activating and creating deferred index IDX_RMGM_IMPORT_DNA
> gbak:cannot commit index IDX_RMGM_IMPORT_DNA
> gbak: ERROR:operating system directive CreateFile failed
> gbak: ERROR:Das Gerät ist nicht bereit.
> gbak:activating and creating deferred index IDX_RMGM_IMPORT_Height
> gbak:activating and creating deferred index IDX_RMGM_IMPORT_Id
> gbak:cannot commit index IDX_RMGM_IMPORT_Id
> gbak: ERROR:operating system directive CreateFile failed
> gbak: ERROR:Das Gerät ist nicht bereit.
> gbak:activating and creating deferred index IDX_RMGM_IMPORT_Ignored
> gbak:activating and creating deferred index IDX_RMGM_IMPORT_Invalid
> [...]
> 
> 
> The result where deactivated indices.
> 
> Am I right that the CreateFile was when firebird tries to create temporary
> files?

Very, very likely.

What version are you running?

{This is worthy of a tracker case -- the file path/name should be included in 
the message.  Do you mind creating it?}


Sean


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel