[RESOLVED?] Disc/partition access conflict with parallels

Scrivener Scrivener for macOS
1

Hi there,

I have my Macbook Pro set up in the following (unconventional) way:

On my original internal drive, I have my OSX 10.8 system partition and a bootcamp system partition (win7 x64 Ultimate SP1)
On a secondary HDD installed in place of the optical bay, I have three partitions:
one for my mac data (mac os extended journaled). My home folder has been moved there, so this is the default place to write data for all well behaved software (that includes Scrivener :slight_smile: ).
one for my PC data (NTFS)
one for media files

I use primarily scrivener mac, so my scrivener files are all in a drobox folder in my Mac Data partition on the secondary hdd.

There is also a dropbox folder on my PC data partition, but it’s separate to avoid conflicts so it syncs with the one on the Mac data partition without any issues.

If I start my Bootcamp parallels session when Scrivener Mac is not running, it starts fine.

If I start my Bootcamp parallels session when Scrivener Mac is running, startup of bootcamp takes ages and then it gives me an error saying it can’t access disk 2 (that’s my PC data partition allocated to the Bootcamp Parallel VM).

I initially had no idea why I would get this error seemingly randomly, so I just rebooted and started the VM from scratch, and that worked.

But recently I pinpointed the issue to Scrivener, which must be accessing some data when it starts that makes the partition where my PC data is located inaccessible.

If I quit Scrivener and start the VM, it loads absolutely fine. If I start Scrivener after the VM has started, it’s also fine, there is no conflict of any sort.

So it looks like while the Mac and PC data are on two separate partitions (on the same disk), the simple fact that Scrivener Mac is launched locks the whole disk for Parallels, which can’t access its data partition on launch.

I tried to authorise the only data directory which Scrivener Mac has to access in the dropbox folder on the Mac data partition, but that didn’t help.

Is this a bug, or is there an option I could use to make sure that Scrivener doesn’t lock the PC partition?

Many thanks!

2

Bump.

Any idea?

Scrivener must access/lock the whole disc, not only the partition where its data is located.

It would be great to hear if there is a way around this behaviour.

Forgot to say Scrivener is the only app that does that. If I start say Final Draft on the Mac, which accesses its files in the same Mac data partition, it doesn’t cause any issues when I start my Bootcamp VM.

Thanks!

3

Any chance for a reply from the team, or should I just strike scrivener off the “well behaved software” list?
I can understand if nothing can be done, but I find the lack of answer disappointing (and surprising).

4

Okay, I suppose it was unrealistic to expect support for a problem I’m probably the only one to experience.
Not impressed with the silence, but I guess you have better things to do :slight_smile: .
Keep up the good work.

5

I have nothing to add to the discussion, and I don’t know what tools the moderators on this forum have to find unanswered posts, but there is a link available to everyone to find all posts with no replies in them. By replying to your own question, you remove yourself from at least that list, which makes it harder for the busy support people to notice that you haven’t had any questions answered. Add to that people ruling out their own advice because they have no experience with parallels, and that leads to your post sliding quickly into obscurity.

You might try emailing support directly, since I believe that’s the first priority of Lit & Lat support. The email addresses can be found at literatureandlatte.com/contact.php

6

Yup, that’s exactly the problem. I start off the day going e-mail support queries, then after that, responses to my messages on the forum, then messages with no responses, then anything recent—and finally if I have time and I’m not doing anything else and it’s not already 10pm :slight_smile:, I get around to poking through threads I haven’t seen yet. Best results are always going to be directly through e-mail. We have three people that spend much of their time just answering e-mails. That all said, it’s still no excuse, I’m sorry you’ve been sitting on a problem for days.

Now as for the problem, that is interesting because I had that same problem a few years ago. I never could fix it, and I wasn’t really needing the Bootcamp partition anyway, so I just let it go and stuck with regular VMs. It’s quite strange that Scrivener would have any impact at all upon a Windows partition. That seems like a very low-level thing to me, and to my knowledge it doesn’t even do anything low level, and NTFS disks are locked to OS X anyway. It’s just a normal Cocoa application, working on the surface of the OS. What is more likely is that one of the OS X frameworks it requires is doing the locking, or less benign, some method employed in the software is triggering a bug deeper in the operating system.

Keith, the developer, is on leave right now, so the person that would know best is not available to give you an answer, but I’ll make sure he sees this when he gets back.

7

Thank you both, I’ll remember emailing in the future, I always had a good experience posting in the forum in the past, which is why it remained my first port of call for support. I never thought bumping the thread would be counter-productive, so I’ll remember that as well :slight_smile: .

Amber, it’s good to know you can reproduce the issue as well, as it sure is not a situation that every user is going experience.

I’ll wait for Keith to comment on this when he is back, it does look like something low level indeed. I just can’t find any reason why Scrivener would have to access the NTFS partition, so my guess is that it somehow locks the whole disk instead of just the partition it has to access, hence locking the NTFS partition out of Parallels reach.

It’s not a OS X wide bug (unless the function called is very specific and not used by other apps), as I only experience this issue with Scrivener. My other Mac apps access the same Mac data partition without locking out the pc partition for the bootcamp VM.

8

We try to be prompt on the forums, but right now one of us is on vacation so things are stretched a bit thin.

I should clarify: I have had this problem in the past, but I no longer have that partition, and I don’t think it had anything to do with Scrivener. It happened after I ugpraded to Lion, so I’m sure that’s all it was. The initial 10.7.0 upgrader certainly was not bug free.

I agree. I run VMs all day long (with Scrivener, mind) since I have to support Windows as well. So I don’t think this is something specific to any one piece of software. My guess is something is getting triggered in an OS sub-system. I have no idea what or why, but nothing else really makes any sense.

It might be worthwhile to try a safe start. Just log out of your account, log back in, and keep the Shift key held down from the moment you click the login button until you are logged in. That will keep all background stuff from loading, so you’ll probably log in nearly instantly. With that set up, run nothing except Parallels and Scrivener and see if you get the same problem. If you don’t, then start going through your login items one by one, launching them and retesting until it breaks. When it does, you’ll know the potential culprit. Try doing another safe start, and this time only run the three programs together and see if it messes up still. If it does you know it’s just that one program. If it doesn’t it might be a combination and will require more testing.

9

Agreed re Lion. It was so buggy when I tested it that I skipped it entirely, and stuck to Snow Leopard until I could move to Mountain Lion. In fact I was forced to stay on Lion for a short while when I bought my MBP 13 2012, and the HD4000 graphics bug was a nightmare. Mountain Lion is a great OS though, mostly stable as far as I can see.

I tried to boot in safe mode, but while Scrivener loads fine Parallels refuses to load as virtualization is disabled and it can’t load its drivers.

While I agree it must be something low level, it is only triggered by Scrivener so let’s wait until Keith is back and can have a look at this. He might know what could trigger this behaviour.

Thanks for your help!

10

Hi,

The only thing I can think off of the bat is that Scrivener monitors for disk dismounting, to ensure that the disk a project is running from is not dismounted while the project is being used. I’m wondering if registering for that monitoring process is causing what you are seeing. To test this, please download and run the following version of Scrivener:

literatureandlatte.com/dlbet … skTest.zip

This version of Scrivener doesn’t register for disk dismounts. Please let me know if it makes any difference.

All the best,
Keith

11

Hi Keith,

Bull’s eye with your first arrow, sir :slight_smile:

No conflict with parallels/bootcamp with this test version, loading the same project from the same data partition.

Do you have a way to monitor if a partition is dismounted, rather than the whole disk?

If you can do that instead, then the problem will be solved without losing any existing protection (I do understand the reason why you are doing this).

Otherwise, I guess we’ll need an option to disable the monitoring if we want to favour compatibility over data security.

In the meantime, is it safe for me to copy the test app over the latest release one (mine is build 20116 I think), or is it unstable in other ways?

Many thanks,

Manni

12

Curious. As far as I know, there is no other way of monitoring partition dismounts. Most apps don’t need to do this sort of thing, but Scrivener needs to prevent any disks from dismounting that contain an open project, since the whole project is never held in memory so data loss could ensue. Until I can find a better solution, for now I have added a hidden preference, “DisableDeviceUnmountMonitoring”. To use it, type the following in Terminal.app:

defaults write com.literatureandlatte.scrivener2.plist DisableDeviceUnmountMonitoring YES

Then hit return. From the next time you launch Scrivener, it will no longer monitor dismounts. This option has been added to the next update.

In the meantime, yes, it’s fine to copy the text version over the latest release - if anything, this version is more stable, as it’s the latest build and we are days away from releasing it as 2.4.

All the best,
Keith

13

This is great, thanks very much indeed.

14

Just to confirm that the flag/preference works perfectly with the 2.4 version released yesterday.

Thanks again for the quick fix!

Manni

15

Glad to hear this was easily solved. I was worried, given the nature of it, that it would be one of those annoying things you’d have to live with.

16

Hi there,

I tried to re-install my scrivener version from the app store so it keeps up to date automatically (it installed V2.4.1 build 22949) but that build doesn’t seem to take into account the flag to solve the mounting issue. I tried to retype the flag option in Terminal, but that didn’t help. I had to revert to V2.4 to get it to work again. It might be related to the latest OS X update which I installed yesterday, but it’s unlikely as I tried to reinstall both version (2.4 L&L and 2.4.1 App store) and only the 2.4 L&L seems to take the flag into account.

Please could you check and let me know? I’d like to be able to use the latest and greatest build :slight_smile: .

17

Just to ad that I tried installing the latest 2.4.1 build from the L&L website (build 22817) and that one works fine.

So the issue is only with the App Store 2.4.1 (build 22949).

18

Okay, I was going to say the two versions are in sync at this point, and if there is ever a discrepancy it is always in the other direction as it takes Apple a while to publish updates that are otherwise instantly available from our servers. As for keeping the software up to date, we’ve always had a built-in notification and update system in the standard version. The “Check for Updates…” menu command in the main application menu can be run at will, or in General preferences, you can set the auto-check to be performed at whatever interval you prefer.

19

Hi Amber,

The builds are not in sync (the app store one is newer), as long as the latest build for L&L is the one you can download from the website as a demo (I didn’t find any other place to download the update).

It’s not a big deal as I can update manually, I just hope that the support for this workaround hasn’t been taken out by mistake.

20

By that I meant the version numbers (not the build number) and what principle features can be in sync, are. There are countless variations between the two however, as the Mac App Store has restrictions that do not exist for self-published software. It is very likely that these restrictions are what cause the bug you experience—most likely the sandboxing framework, which is notably buggy. The build number is always going to be different—that increments whenever Keith compiles and there can be hundreds of test builds in between the direct-sale compile and the MAS compile. That doesn’t mean anything significant has changed short of minor error corrections.

The main Scrivener application menu contains a “Check for Updates…” menu command, and like the Mac App Store, this can be set to automatically be done for you in the General preferences pane, either as a notification that you must confirm, or as a fully automatic process that happens in the background whenever we publish an update.

Like I say, the bug is probably a result of using the frameworks we are forced to use on the MAS, not any particular feature difference in Scrivener. The MAS version must use a portion of the operating system that the direct-sale version does not use, and that portion of the operating system is still relatively new and contains many known bugs and conflicts that are pending at Apple. This means any program using those frameworks will have those bugs, there is nothing we can do about that. Using the direct-sale version avoids this framework, so it is an inherent “workaround”, not a specifically designed one. To put it to an analogy, it is like avoiding a street with suspension damaging potholes all throughout it. The other street just doesn’t have those potholes and will continue to be a more stable route until the city (Apple in this case) gets around to fixing the road.