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

#1

There seems nothing wrong with permissions - I save sessions below the user’s documents folder like everything else.

#2

Have you perhaps used Ardour as Administrator in the past and the folder is owned by Admin, not your user? – Then again you said permissions are fine.

Also check if the preferences are owned by your user: %localappdata%\Ardour8\.

Is this just a specific session? Can you create new sessions and open then in read/write mode?

#3

All v8.4 created sessions show that issue. I don’t have older sessions.

My entire user folder uses inherited permissions with full control given to SYSTEM, Admins, and the user itself.

#4

It works for now. No clue what the issue is… I just used another location on another drive and then moved back to the original location… very very strange.

#5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

#6
#7

The issue has been reported a few times now, and is caused by Microsoft OneDrive synchronizing the User’s Documents folder to the cloud.

The solution is to move use a different folder for sessions that is not backed by Cloud storage but resides on the local disk.

#8

I’ve always stored my projects quite deliberately in OneDrive synced folders for protection. This has always worked fine.

Now all of a sudden Ardour insists on opening in read-only mode once OneDrive has synced the file. If you disable syncing when you create a session it can be edited and re-opened as much as you like, but as soon as OneDrive is allowed to sync it once then it will only open in read-only.

I’m using the same version of Ardour as always (6.9 in my case), so I assume this is some change in OneDrive behaviour that is causing the problem.

What is Ardour seeing that it doesn’t like that causes it to open read-only? Is there something that can be changed in OneDrive to avoid this?

Not storing projects on synced folders is not really desirable in many cases, especially if many projects are already in such locations.

Thanks for any suggestions.

#9

We don’t know what OneDrive is doing. We just know that there is no problem if the session is moved to a folder that isn’t in use by OneDrive. We’re not likely to spend a lot of effort investigating this either - we don’t have the resources to track down problems on Windows that are caused by 3rd parties. If someone else manages to investigate and gets some answers, we’d be happy to use that information.

#10

one thing that can be said: read-only mode occurs when Ardour tries to open various session-related files in read/write mode and it fails, but the file can be opened in read-only mode.

best guess: OneDrive marks all the files are read-only while syncing.

#11

Yes this would make sense during actual syncing, but the issue persists after sync has completed. Files certainly don’t appear as read-only within file explorer so it’s puzzling how they could appear to Ardour that way. Appreciate there’s unlikely anything Ardour can do about it and the only solution would be to try to find out why OneDrive’s behaviour has changed. If I manage to get to the bottom of it I’ll post something here. Edit: just discovered this is only affecting some OneDrive synced folders, not all. So may well be a local issue with those particular folders.

#12

Does Ardour log anywhere the failure to open a file in rw?

#13

Nope. We just proceeed in read-only mode. If you get a debug build from nightly.ardour.org, and run from the command line with -D fileutils it would show some more information.

#14

I suspect this is an issue with Windows where concurrent file access is not generally possible. I suspect that OneDrive process opens the file read-only, which prevents Ardour from writing to it.

Then again searching the internet for “OneDrive read-only” find a lot of possible reasons… incl antivirus software causing this.

#15

For the record, I recommend against this practice in most cases. There is to much danger of issues, either from the service itself, or from the file systems you are sync’d to. For instance if you sync to a case insensitive filesystem, and all your cases of your files gets screwed up, and then also sync to a case sensitive one. This is one example. My students have constant problems doing this type of workflow in Google Drive for instance because of similar issues. That is why I teach them to ALWAYS zip your file before uploading it to a sync service like this, that way it provides a layer of protection from similar issues.

  Seablade
1 Like
#16

If you open OneDrive in Windows it might be worth checking if the troublesome projects did get uploaded. I’ve some files here which I added to my OneDrive folder 4 months ago and it still says they’re uploading!!

#17

FWIW I uploaded a session to OneDrive and realised that I could open its .ardour file in a text editor without any complaints about it being read-only. So I then ran it in my debugger here and this is the code that fails in the function exists_and_writable() (which is in ‘libs/pbd/file_utils.cc’):-

  DEBUG_TRACE (DEBUG::FileUtils, string_compose("exists_and_writable stat '%1': %2 \n", p, statbuf.st_mode));
  if (!(statbuf.st_mode & S_IWUSR)) { <---- THIS TEST FAILS !!
  	/* exists and is not writable */
  	return false;
  }
  /* filesystem may be mounted read-only, so even though file
   * permissions permit access, the mount status does not.
   * access(2) seems like the best test for this.
   */
  if (g_access (p.c_str(), W_OK) != 0) {
  	DEBUG_TRACE (DEBUG::FileUtils, string_compose("exists_and_writable g_access '%1': !W_OK\n", p));
  	return false;
  }

It doesn’t fail when testing the .ardour file. It fails when testing the directory name at this line in ‘Session::load_state()’:-

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

so I’m not sure if the fault lies with Windows or with Ardour but for whatever reason it seems like Ardour treats OneDrive folders as being read-only.

#18

It’s not “Ardour treating” … g_stat() is effectively a system call, so windows is telling us that it’s read-only.

Unless there’s a weird oversight/error in glib’s implementation of g_stat() for Windows that OneDrive somehow triggers …

#19

Yes and to be fair, that code’s been around for a very long time in Ardour so if it used to work okay, it’s most likely a change in either Windows or OneDrive.

#20

In case anybody’s good with binary stuff, a slightly earlier call to g_stat() delivers the value 16895 for a non-OneDrive folder but it delivers 16749 for a folder within the OneDrive folder.