Bug report #19335

QGis 3.x not updating save status on some machines

Added by Kim Frankcombe about 2 years ago. Updated about 2 years ago.

Status:Closed
Priority:Low
Assignee:-
Category:Browser
Affected QGIS version:3.2 Regression?:No
Operating System:Ubuntu 16.04 Easy fix?:No
Pull Request or Patch supplied:No Resolution:not reproducable
Crashes QGIS or corrupts data:No Copied to github as #:27163

Description

We are running QGis 3.2 on two Ubuntu xenial machines. For one, using /file/save or clicking on the save button on the tool bar saves the file but QGis does not recognise this and leaves an asterisk beside the filename on the top bar indicating a change and always asks if you want to save on exit. The other machine behaves as expected. The issue occurred from 3.0, early adopters through to 3.2 but did not with 2.15 or 2.18

A minor irritation but if others have the same issue it might be worth fixing.

History

#1 Updated by Giovanni Manghi about 2 years ago

  • Status changed from Open to Feedback

same project and datasources on the two machines? maybe different permissions?

#2 Updated by Jürgen Fischer about 2 years ago

But not just on the machine with #19315?

#3 Updated by Kim Frankcombe about 2 years ago

Giovanni

Possible but we all have the same directory structure for our local working directory /srv/wrk/ and each of us are members of a common group and each of us have set chmod -R 2775 for /srv/wrk/ and each have set chown -R username:common group for /srv/wrk/ so I don't think so. However I don't claim to be an expert on permissions and file sharing in Linux - yet. We mount each others work drives in fstab so that we can share files easily. When we mount we do so with the credentials for the common group.

The issue is not project dependant. I can create a new project from scratch and see the same behaviour.

Jürgen

It's my machine that shows the save issue not the one that was having the install issues in #19315. It saves as one would expect.

We still have a three machines running 2.18 which we'll update once the dust settles on 3.

Cheers
Kim

#4 Updated by Giovanni Manghi about 2 years ago

Kim Frankcombe wrote:

Giovanni

Possible but we all have the same directory structure for our local working directory /srv/wrk/ and each of us are members of a common group and each of us have set chmod -R 2775 for /srv/wrk/ and each have set chown -R username:common group for /srv/wrk/ so I don't think so. However I don't claim to be an expert on permissions and file sharing in Linux - yet. We mount each others work drives in fstab so that we can share files easily. When we mount we do so with the credentials for the common group.

very difficult for us to try replicate and troubleshoot. Seems really likely a local issue with your permissions/shares.

#5 Updated by Kim Frankcombe about 2 years ago

Giovanni

I'm doubtful. Remember that it actually does save the qgs file it just does not appear to know that. A permissions issue would block that save.

For clarity all our files are operated on locally. Although we share each others directory we copy the whole project directory to the machine we are working on and then copy it back when altered.

#6 Updated by Giovanni Manghi about 2 years ago

Kim Frankcombe wrote:

Giovanni

I'm doubtful. Remember that it actually does save the qgs file it just does not appear to know that. A permissions issue would block that save.

For clarity all our files are operated on locally. Although we share each others directory we copy the whole project directory to the machine we are working on and then copy it back when altered.

I run only Linux machines at the office, but I would not be able (of course) to replicate exactly your scenario.
This is one of those cases where the reported should investigate more on his/her side and try determine if is as a fact a qgis issue (my bet here is "no") or else.

#7 Updated by Kim Frankcombe about 2 years ago

I agree that it will be hard to replicate and pin down. One piece of evidence in favour of it being a QGis issue is that I did not have the same issue with 2.15 or 2.18.

As I initially noted it is a minor irritation and I flagged it mainly in case I wasn't the only one seeing this in which case we may be able to find a common factor and thus solve the mystery.

Happy to experiment if others see the same issue.

Cheers
Kim

#8 Updated by Giovanni Manghi about 2 years ago

Kim Frankcombe wrote:

One piece of evidence in favour of it being a QGis issue is that I did not have the same issue with 2.15 or 2.18.

on the contrary, I would say that this piece of evidence is against QGIS: if the same project, that gets the same datasources, in the very same infrastructure, etc. work on 2.18 then it should work also on 3.*. If it does not is a regression... now the million dollar question is... what exactly (and in what scenario) regressed? I'm afraid we can't help find the answer (not easy at least).

#9 Updated by Giovanni Manghi about 2 years ago

  • Resolution set to not reproducable
  • Status changed from Feedback to Closed

Reopen if a clear way to replicate is found, thanks.

Also available in: Atom PDF