Fix construction of file based DB name on *NIX systems

Authored by tbaumgart on May 27 2018, 7:16 AM.

Description

Fix construction of file based DB name on *NIX systems

One cannot remove the leading slash which will turn an absolute file
path into a relative one on *nix systems which in turn breaks the logic.

Details

Committed
tbaumgartMay 27 2018, 7:16 AM
Parents
R261:e9b4420650c0: Avoid duplicate deletion
Branches
Unknown
Tags
Unknown
ocoole added a subscriber: ocoole.May 27 2018, 11:04 AM

Hi Thomas,

Apologies that my previous patch screws up on *nix. (I've always suspected that I was not doing a proper fix last time, and ya... it broke.)

I'm not nitpicking, but I don't have the benefit of a Linux OS, and my curiosity really drives me to want to take a deeper look at it.

Hope it's not too much trouble, but very much appreciated if you could provide a little bit more details how you encountered it, say,

  1. Did you use the Open database... / Save as database... dialog?
  1. Were you trying to save (as) or open a local db file?
  1. If you use the Select database dialog, did you enter a filename manually in the File textbox, or did you use the browse file dialog (by clicking on the button to the right)?
  1. What appears in the File text field right before you click OK?

Sorry for the inconvenience, but many thanks indeed for your help!

Apologies that my previous patch screws up on *nix. (I've always suspected that I was not doing a proper fix last time, and ya... it broke.)

No problem. I saw that previous patch and it looked OK to me code-wise.

I'm not nitpicking, but I don't have the benefit of a Linux OS, and my curiosity really drives me to want to take a deeper look at it.

For me it's the other way around - I don't have a Windows build environment. So I know exactly how that feels.

Hope it's not too much trouble, but very much appreciated if you could provide a little bit more details how you encountered it, say,

See D13020 where I explained what I was doing. In fact, I was trying to test this and found two problems.

  1. Did you use the Open database.... / Save as database... dialog?

Yes.

  1. Were you trying to save (as) or open a local db file?

I think it was using save as. Since I don't have DB files, I doubt it was an open of a local db file. Oh, and it was only using SQLITE. I think the problem only occurs with local files but not with DB connections to servers.

  1. If you use the Select database dialog, did you enter a filename manually in the File textbox, or did you use the browse file dialog (by clicking on the button to the right)?

I think I used both which produced the same result.

  1. What appears in the File text field right before you click OK?

The absolute file name (on Unix systems starting with a slash)

Sorry for the inconvenience, but many thanks indeed for your help!

It's a common effort, so we help each other. That is what it is all about.

Hi Thomas,

Thanks for the information and your prompt reply!
After reading up some further docs, I think I know what I've missed last time. (Hopefully I could submit a better fix to replace my last one soon.)

p.s. I also encountered the [Database not empty] bug last time I worked on the patch (so I could confirm it's a bug even before Łukasz's patch)—it complains file exists even when it's newly created. [I haven't come across the second error though (including the Sqlite parse error) (probably because I haven't used online tasks)—probably needs some investigation by Łukasz]

I found the problem with the not-empty database and just fixed it with 9267f93c4d0b5.

Thanks for the fix! BTW, may I ask which qt/kf version are you using? (just for curiosity's sake)

Sure, I use stock openSUSE Leap 42.3 atm, which shows as