DP 4.6: problem saving

[madlab]

Originally posted by pcm:
I am having a similar yet different "permissions" problem. Ever since 4.5, I occasional have files that repeatedly put up error 61 when I try to save. The dialog box suggests I save to a different drive or use a different name.

It's an interesting idea that perhaps it is related to moving projects to and from different drives. I have two machines, one at my studio, one at my home. I wonder if there is a pattern here relating to the projects being opened and saved on different machines. Both machines have the same user name (mine). I sure would like to see this gone.....

Same problem since using 4.5, trying to save on an extended mac formatted 250 go Lacie FW 800drive. As for moving projects, that's not my case. It also happens with projects started on the same mac.

[magicd]

I've never tried to change the permissions on a file when it is open.

When DP creates a session file it sets the file permission to read/write. DP doesn't change file permissions in any other way.

When you save a file in OSX, the operating system makes a new file. The OS names the new file with the name of the existing file. Once the OS has verified that the new file has been properly created, it deletes the original file. If the original file has a read-only permission set, the OS will not delete the file and you'll get an error message. I've seen several different error messages pop up when this happens.

How does a file permission get changed (without the user doing it manually)? That I don't know. I have heard speculation that backup software could do this. Possibly moving files around could do this. I suspect that the OS may change file permissions somehow, based on direct experience troubleshooting systems.

Many things that an application does are actually carried out by the operating system. Save is one example. Print is another example. If there is something bad happening in the OS or with the hard drive, the symptom may show up in the application software, even though the application software is not doing anything wrong.
With the customer I helped out previously, they had continuing file permission problems, regardless of running Disk Utility, reinstalling application software, and trying to save to different drives. Eventually the customer reinstalled the OS and the problem vanished.

I am very cautious about recommending an OS reinstall. I'm more comfortable suggesting that a second OS gets installed to a different drive and the computer gets booted off that OS to see if there is any change in symptoms. If you have a second drive, that's a practical and far less traumatic way to check the OS than doing a reinstall and hoping something changes for the better.

Magic Dave

[qo]

Originally posted by pcm:
I am having a similar yet different "permissions" problem. Ever since 4.5, I occasional have files that repeatedly put up error 61 when I try to save.

<snip>

It's an interesting idea that perhaps it is related to moving projects to and from different drives. I have two machines, one at my studio, one at my home. I wonder if there is a pattern here relating to the projects being opened and saved on different machines. Both machines have the same user name (mine). I sure would like to see this gone.....

Error -61 is as follows:

wrPermErr -61 Read/ write permission doesn••™t allow writing.

The fact you're using two machines and copying between them might be a clue pcm. While the machines have the same user (you), do both these users have the same UID? My guess is that they don't, since UID's are created sequentially unless this is specifically overridden.

On both machines, open Terminal and type the command "id" like this:

Code: Select all

QuantumOnion:~ qo$ id
 uid=504(guest) gid=20(staff) groups=20(staff)

Check to see if the UID matches for both (you's). If they don't, then you need to manually make these equal by finding a common free UID on both machines and changing your UID to this common one. This is achievable in a couple different ways, but let's check first to see if the UID's are indeed different.

<small>[ August 12, 2005, 09:45 AM: Message edited by: qo ]</small>

[pcm]

Originally posted by magicd:
I
With the customer I helped out previously, they had continuing file permission problems, regardless of running Disk Utility, reinstalling application software, and trying to save to different drives. Eventually the customer reinstalled the OS and the problem vanished.
Magic Dave

I actually tried that. I did Erase And Install. A total clean slate. The problem returned more or less immediately.

I have two differently machines, in two different locations. Projects that have trouble in one location have trouble in another. And this can rear it's head at any time.

Also, as far as the OS changing permissions on a file, how does one explain why DP won't save a file (error 61 - i.e., save under a different name or different location), but upon a second attempt, it will? Note however, on the second attempt, it will ask me if I want OVERWRITE the original version. So it would seem that DP can't "update" the original. Maybe it's OS related, but why ONLY DP, and why only since 4.5?

[pcm]

Originally posted by qo:

Originally posted by pcm:
I am having a similar yet different "permissions" problem. Ever since 4.5, I occasional have files that repeatedly put up error 61 when I try to save.

<snip>

It's an interesting idea that perhaps it is related to moving projects to and from different drives. I have two machines, one at my studio, one at my home. I wonder if there is a pattern here relating to the projects being opened and saved on different machines. Both machines have the same user name (mine). I sure would like to see this gone.....

Error -61 is as follows:

wrPermErr -61 Read/ write permission doesn••™t allow writing.

The fact you're using two machines and copying between them might be a clue pcm. While the machines have the same user (you), do both these users have the same UID? My guess is that they don't, since UID's are created sequentially unless this is specifically overridden.

On both machines, open Terminal and type the command "id" like this:

Code: Select all

QuantumOnion:~ qo$ id
 uid=504(guest) gid=20(staff) groups=20(staff)

Check to see if the UID matches for both (you's). If they don't, then you need to manually make these equal by finding a common free UID on both machines and changing your UID to this common one. This is achievable in a couple different ways, but let's check first to see if the UID's are indeed different.[/b]

Interesting.

First, I would be leery about playing games like this, for fear of messing something else up. While I primarily use these two machines, I actually have others (office machines, powerbook, etc.) and really don;t want to play games like these just because DP has an issue like this.

I say this because ONLY DP does this. It may be OS related, but like I say, only DP does this. It shouldn't be so sensitive to the permissions thing to break this easily. That what I think....

BTW, I tried the command, and got the response - command not found

[dix]

pcm. You seem to be the only one that can repeat this w any regularity so: What OS are you using? Have you investigated the status of the permissions of the document when you get the error as Magic D suggested?

btw I never move files from one machine to another and I'm getting the error, albeit far less frequently than pcm it looks like.

thanks qo for the little osx tutorial. maybe one day i'll get it.

[qo]

Originally posted by pcm:
BTW, I tried the command, and got the response - command not found

pcm, sounds like your environment path doesn't include /usr/bin/ so you'll have to type the complete path along with the command, like this:

/usr/bin/id

It's a harmless command.

You can verify the contents of your PATH environment variable with:

Code: Select all

QuantumOnion-iMac:~ qo$ set | grep PATH
 PATH=/bin:/sbin:/usr/bin:/usr/sbin

I can understand that you don't want to go under the covers. Unix is a pretty forbidding place for the uninitiated. Though, I must say, it's a beautiful place (elegant and rich) if one has the time to understand its design philosophy.

<small>[ August 12, 2005, 07:34 PM: Message edited by: qo ]</small>

[larrytheo]

First of all, the error I see is -61, not -51. I've been working on the same machine for several years now and the file has resided in the same place for quite a while, also.

I was away for a long weekend, so I haven't had a chance to try any of this snooping around, but I will. I will also try Repair Permissions, as it's been a little while since I did that.

It seems odd to me that I have had this problem only with one file if the problem is not session corruption, but, hey, we're talking about computers here!

What a mess.

The O

[dix]

I finally got this error again and checked to see what it's permission status was. It was still Read & Write and everything else normal except the little lock was latched. I don't think this is how it's supposed to be (?) I unlatched it but still could not get the file to save ("create a copy as" worked fine though). ...Be nice to get this figured out since create A Copy As doesn't copy the Undo History.

[BobK]

I'm probably the one magic was referring to. I had a similar save problem back in May - my errors were Type -47 ( in DP 4.52). Here's the thread:

http://www.unicornation.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=1;t=002844

We never figured out the cause.

The only thing that got rid of the problem for me was reinstalling the OS. A bit of a pain, but after all the headscratching and time spent troubleshooting, it was worth it. The problem hasn't happened since the re-install. I think that was right before I went to Tiger (via Upgrade install), and it hasn't happened since the upgrade either.

Before I reinstalled the OS, I ran diagnostics (TechTool Pro, DiskWarrior, Apple Hardware Test) and re-installed DP. None of this helped.

Note that in my case, the file was actually saved even though I got the error.

<small>[ August 21, 2005, 11:45 PM: Message edited by: bobk ]</small>

[pcm]

I went one better. I completely erased my drive and started over. The problem was back literally the next day. All I can say is this was never an issue before 4.5, and I have not see this with any other app. Furthermore, I have this issue with two different machines, one hundred miles apart.

As far as I am concerned, the jury is in. What other counclusion can there be?

I would very much appreciate it if this would problem could be made to go away with the next update.

[Kubi]

I can *almost* count on DP to have the first "Save" of the day result in a error -47 message (if I remember the number correctly...) However, a few non-scientific tests seem to suggest that DP saves the file despite the error message.

My usual "fix" is to do apply some meaningless change to the project (i.e. record-enabling and disabling a track) and save again. 99 out of a 100 times, DP then saves fine, and usually continues to do so throughout the remainder of the session. (And I use command-S a LOT.)

Very rarely I also get a similar error message (without number) after recording. DP will claim the Takefile did not get recorded, but then the file is there without any problems, and continues to play back and act normal. Usually I then reboot DP just to be safe, but even if I don't the problem usually doesn't return.

At first this whole thing made me a tad nervous, but since so far this behaviour has resulted in zero losses, I am getting a bit more Zen about it... plus I make constant copies ("Save a copy as") of the files in progress, so I have dozens of project files to fall back on should the sh.t hit the fan for real.

<small>[ August 19, 2005, 10:58 AM: Message edited by: Kubi ]</small>

[mersis]

Qo I think that was me that gave the -50 report ..... foo test ?

Magicd That also might have been me as I gave some files to motu a month or so ago

in my case the permission were not set to read only the problem is still there..... WHEN I save the file on my Audio drive

I have an alternate OS drive which I am using as my motu sessions storage

For pepople experiencing this I suggest trying another HD to save and see what happens

[mersis]

Oh And BTW when I would get this error ( on saving on my audio drive ) back round processing was infinite ...meaning as soon as a file was analyzed ( for pitch correction only not beats or tempo )

it would eave the top of the pile and go right down to the bottom again

[modular]

I can *almost* count on DP to have the first "Save" of the day result in a error -47 message (if I remember the number correctly...) However, a few non-scientific tests seem to suggest that DP saves the file despite the error message.

My usual "fix" is to do apply some meaningless change to the project (i.e. record-enabling and disabling a track) and save again. 99 out of a 100 times, DP then saves fine, and usually continues to do so throughout the remainder of the session. (And I use command-S a LOT.)

Very rarely I also get a similar error message (without number) after recording. DP will claim the Takefile did not get recorded, but then the file is there without any problems, and continues to play back and act normal. Usually I then reboot DP just to be safe, but even if I don't the problem usually doesn't return.

At first this whole thing made me a tad nervous, but since so far this behaviour has resulted in zero losses, I am getting a bit more Zen about it... plus I make constant copies ("Save a copy as") of the files in progress, so I have dozens of project files to fall back on should the sh.t hit the fan for real.

<small>[ August 19, 2005, 10:58 AM: Message edited by: Kubi ]</small>

As of yesterday, I've been experiencing this problem as well. I running DP under DAE and my workaround was to toggle a play enable button on any track. It would then save correctly. After much trial and error I found that the source of the problem was using Groove Agent. I run this plugin using a VST->RTAS convertor. When I deleted the track that had Groove Agent on it the file saved with no problem. My new workaround is to render the Groove Agent instrument to audio, delete the plugin and then save normally. Since this is a VST->RTAS intrument, it's hard to blame MOTU for the problem. Would be nice if things worked as they should though.