Ardour 8.4 on Win11/amd64 always opens session in read-only mode

[x42 (Robin Gareus)]

@John_E

there’s no such thing as a write-protected folder on Windows.

Sure there is. Create a folder as administrator, then try to write to it as user.
Can you check, say C:\Program Files? A normal (not admin) user should not be able to write there.

@John_E

And the only disks I know that are write protected are CD’s / Blu-ray disks and the like.

yes, or a session on a read-only network share

Some External USB disks have a switch, but more commonly this happens after a disk-scan failed. Apparently you can also mark disks read-only by setting an attribute: either on partition or file-system level.

We may not need to worry about the latter, since that likely triggers warnings earlier, yet I hope g_access() also correctly reports false there.

[John_E]

Okay it gets interesting here…

I’ve access to C:\Program Files so I copied a session into C:\Windows\system which required me to give Administrator permission. I then edited the session permissions so that ordinary users only have read permission and I opened it in Ardour - initially with your original code for PBD::exists_and_writable().

Interestingly, this didn’t give me any initial message when loading the session and once in the session, it allowed me to edit the timeline and even use Session->Save, all without seeing any errors. But once I tried to Quit, I saw the following messagebox:-

So I then rebuilt the code using my own changes (from above) and that gave me exactly the same behaviour at runtime.

[lennier]

Unfortunately I’m running an old version of Ardour still so can’t really test any nightly builds etc. All I can offer to potentially help is my observation that my older existing Ardour projects seem to still work fine and can be opened, edited and saved as normal. Any new projects though will initially work (by disabling OneDrive sync when creating them) but as soon as OneDrive is allowed to sync the files they immediately become read only as far as Ardour is concerned. Likewise for an old project if you save a new copy.

At the moment I’m working around the issue but it’s great to know that you’re looking at a solution as I hope to upgrade Ardour in the near future so hopefully I might be able to maintain my previous workflow.

[x42 (Robin Gareus)]

I just applied a variant of this in 9.0-pre0-1204: Fix false read-only detection of sessions on Windows with OneDrive · Ardour/ardour@6c8a2ec · GitHub

[John_E]

With regard to my post from Apr 17th (the one about C:\Windows\system) I was taking another look at it this morning. The initial problem (OneDrive) is fixed now in Ardour - though not yet transferred to Mixbus - but when opening sessions or saving files, their read-only status only gets detected if the file’s “read-only” flag is set. If it’s read-only due to a permissions issue, that doesn’t get detected until trying to close the session. So in theory, a user could do hours of work, thinking it was all getting saved when in fact, it wasn’t.

So to handle permissions issues, maybe a possible solution would be to check the file’s date & time just before saving and then check again after an attempted save. And if the date & time are identical, flag that up to the user?

[x42 (Robin Gareus)]

@John_E

So in theory, a user could do hours of work, thinking it was all getting saved when in fact, it wasn’t.

Ardour saves a session at session creation, and then periodically saves the session every 2 mins (unless actively recording), and before each record pass. So this would show up much sooner.

Besides you can always do a save-as…

@John_E

So to handle permissions issues, maybe a possible solution would be to check the file’s date & time just before saving and then check again after an attempted save.

When saving a session, a temporary file is written to disk in addition to the existing session file in the same folder. Only if this succeeds the session file is replaced with this temporary file.

In addition to your concern this also ensures that there is sufficient disk-space.

[John_E]

@x42

When saving a session, a temporary file is written to disk in addition to the existing session file in the same folder. Only if this succeeds the session file is replaced with this temporary file.

That’s true - and with respect to the temp file I see lots of errors in Ardour’s error log that look like this:-

but there’s no actual message box, so if the user wasn’t looking at the log he’d never know there was a problem. I’ve noticed this line in Session::load_state():-

_writable = exists_and_writable (xmlpath) && exists_and_writable(Glib::path_get_dirname(xmlpath));

and the basic problem is that _writable is being set as true in this case, when it should be false (probably just an extra test is needed somewhere?)

[x42 (Robin Gareus)]

One would think that a blinking red light attracts some attention… and a user then clicks it and read the message(s).

But you’re probably right that we should use a popup message window for this case.

[ccaudle (Chris)]

@x42

One would think that a blinking red light attracts some attention…

On my monitor the red indicator in the corner for log errors is very small, and I would often not notice it blinking if I was concentrating on channel controls.

[John_E]

Hi Robin - I’m not claiming it’s an elegant solution but g_rename() looks like it might help here (i.e. it can show us when a file is read-only for reasons of ownership - even though its read-only flag might be unchecked).

There are calls to exists_and_writable() at line 1012 in Session::load_state(). I tested it here by expanding those calls to the following code and Ardour then correctly detected read-only session files, regardless of whether it’s because their read-only flag was set or whether it was a permissions issue. In either case when the session got loaded:-

1. I saw a popup warning,
2. Session->Save got grayed out - and,
3. Ardour didn’t attempt autosaves etc.

Maybe that’ll give you some ideas for a better fix? I tried it with OneDrive sessions too here and it didn’t cause any problems.

if (_writable = exists_and_writable (xmlpath)) {
	std::string tempname = xmlpath + "-tmp";

	if (0 == g_rename (xmlpath.c_str(), tempname.c_str())) {
		if (0 == g_rename(tempname.c_str(), xmlpath.c_str())) {
			_writable &= exists_and_writable(Glib::path_get_dirname(xmlpath));
		} else {
			_writable = 0;
		}
	} else {
		_writable = 0;
	}
}

[x42 (Robin Gareus)]

Are you proposing to move the session file during session load? That sounds dangerous to me. If at all, make a copy or try creating some other temporary file.

But this means that ::exists_and_writable() API is useless, and all users of exists_and_writable would need to do a similar hack.

I think we should rather fix exists_and_writable and not change Session::load_state at all (or remove exists_and_writable).

[John_E]

It doesn’t move anything to a different folder. It just renames the file temporarily. So a file called whatever.ardour would become whatever.ardour-tmp and if successful, it’d immediately then go back to its original name (though of course, renaming all falls down if there’s already a file with the relevant name ). Just an idea to stimulate some thought maybe…

[x42 (Robin Gareus)]

@John_E

It just renames the file temporarily

which IMHO is really bad practice, even more so during an operation that should leave the session as-is. I can see various edge cases where this could lead to data loss.

If a mechanism like this is really required. try copy or create a new file, leaving the original files as-is.

[John_E]

But the problem with copying the file or creating a new one is that it doesn’t guarantee that the original file wasn’t read-only.

Needs thinking about…