QSettings problem when input file is a link

[damre22]

@m-sue I tried that too but I got the same behavior and @mrjj is correct, it's not a ".lnk" file. Thanks :)

[mrjj]

@damre22
Im a bit surprised the symbolic link dont work.
Most programs sees the actual file and have no awareness of
of the link.
Did you try both types (symbolic and hard link ) ?

[damre22]

@mrjj sadly the file i need to reference is on another partition so my only option is symlink, I cannot use hard link between different drives

[mrjj]

@damre22
ah, i forgot that limitation.
Have you tried with QFile and see if that will read correctly via the link?
It might be a deeper issue that QSettings.

[damre22]

@mrjj said in QSettings problem when input file is a link:

Have you tried with QFile and see if that will read correctly via the link?

Yes I tried, the file is not even considered a link.

    QFile file("test.ini");
    qInfo(file.symLinkTarget().toLatin1().data());

returns a null string but is binded to the correct file. However i think this is correct because that file technically is not a link

It might be a deeper issue that QSettings.

I think I can agree on that

[mrjj]

Ok
it seems that symbolic links are not considered for symLinkTarget()
as docs says
"Returns the absolute path of the file or directory a symlink (or shortcut on Windows) points to"

So it sounds like only .lnk is handled/known

Just to be sure i understand your setup.
In the build folder/deploy you have test.ini link to the real
file on other partition?
And using that with QSettings do odd things where as same code with
real file directly in place, just works?

[damre22]

@mrjj said in QSettings problem when input file is a link:

In the build folder/deploy you have test.ini link to the real
file on other partition?

Exaclty

And using that with QSettings do odd things where as same code with
real file directly in place, just works?

yes, with the real file the same code works fine, by the way I opened a bug on bugreports.qt.io
https://bugreports.qt.io/browse/QTBUG-64121
because I think this is a problem with QSettings

[kshegunov]

Check if a regular file QFile can be opened, read and written when it's a symlink. If that is okay, then the problem is with QSettings, if not probably the problem is with the underlying file system('s API/integration).

[mrjj]

@damre22
Good i was about to suggest that since it seems reproducible in small sample and
it sounds like you tested its not just a "user" error.

Could you perhaps, show the mklink commandline you used in the bug report for
completeness. ?

[damre22]

@mrjj yes I will update the bug report, thank you so much

[damre22]

@kshegunov I will check that too and I will update the bug report if I find something new, thank you

[Sylvain]

Hi,

I also had a QSettings::AccessError when trying to QSettings::sync() on a config.ini file on file system ext4 + symlink with Qt 5.7.1 on raspbian OS Stretch

Here is my snipet to reproduce locally:

    mysettings->sync();
    QSettings::Status s = mysettings->status();
    QString msg;
    switch(s)
    {
    case QSettings::NoError:
        msg = "No error occurred";
        break;
    case QSettings::AccessError:
        msg = "An access error occurred (e.g. trying to write to a read-only file).";
        break;
    case QSettings::FormatError:
        msg = "A format error occurred (e.g. loading a malformed INI file).";
        break;
    }
    qDebug() << "writing configuration_file" << mysettings->fileName() << "status:" << msg << endl;

In my debug output I get:

2019-04-01 12:08:53 : writing configuration_file "/home/pi/config.ini" status: "An access error occurred (e.g. trying to write to a read-only file)." 

and the file

pi@machine:~ $ ls -l config.ini 
lrwxrwxrwx 1 pi pi 28 avril  1 12:08 config.ini -> /etc/config/config.ini

the file is actually perfectly writable by pi users

pi@machine:~ $ ls -l /etc/config/config.ini 
-rw-r--r-- 1 pi pi 829 avril  1 12:08 /etc/config/config.ini

Is it fixed in newer version of Qt?

The idea behind using symlink, is a backward compatible path, + using etckeeper in /etc/

A suggestion for work around?

Regards,
Sylvain.

[Sylvain]

Replying to myself:

The bugrepport said is is fixed for 5.10.1

https://bugreports.qt.io/browse/QTBUG-64121

And it can be made to work with correct folder permissions :

$ ls -ld /etc/config/
drwxr-xr-x 2 root root 4096 avril  1 11:15 /etc/config/
$ sudo chgrp pi /etc/config/ 
$ sudo chmod g+w /etc/config/
$ ls -ld /etc/cleandrop/
drwxrwxr-x 2 root pi 4096 avril  1 11:15 /etc/config/

resolving simlink doesn't helps

    // resolve symlink
    // https://bugreports.qt.io/browse/QTBUG-64121
    QFileInfo info(_configuration_file);
    if (info.isSymLink())
        _configuration_file = info.symLinkTarget();

So I removed this fix, and fixed the folder permission and it worked.