Changing a Folder Name in the Finder When a File is Open Causes the Loss of Control of the Lock File

[Hangman]

Changing the folder name in the Finder (on macOS) when a file is open causes a loss of control of the lock file...

So subsequently the file can't be opened in the other Affinity Apps using Edit in...

Reverting the Folder name reverses this outcome allowing the file to be both saved and opened in the other Affinity Apps using Edit in...

While the expectation would be that you wouldn't be able to rename the File itself in the Finder owing to the lock file, I'm unsure whether this is also expected behaviour for the Containing Folder...

Folder renaming with open files is allowable on macOS and works without issue in v1 but of course that was before the introduction of lock files so I just want to get some clarification as to whether Folder renaming in the Finder with open files is now no longer possible with Affinity 2 files or whether this should still be possible...

[walt.farrell]

The failure to Save seems reasonable to me, and it feels appropriate to suggest Save As instead.

I would also think it reasonable for Edit In to fail, and it's good that it didn't lose the file (as has happened in some scenarios in the past) but there should be a better error message, I think.

It will be interesting to see what the Serif staff think.

[loukash]

20 minutes ago, Hangman said:

that was before the introduction of lock files

I, for one, wish that those lock files were optional. I've already had to work around them when scripting certain workflows that involve Affinity documents.
For me, these lock files are definitely of no help whatsoever.  

</rant>

Other than that, the warnings here obviously serve their purpose. I don't see an issue with them.

[Hangman]

19 minutes ago, loukash said:

Other than that, the warnings here obviously serve their purpose. I don't see an issue with them.

33 minutes ago, walt.farrell said:

The failure to Save seems reasonable to me, and it feels appropriate to suggest Save As instead.

I very much expect this is the expected/anticipated behaviour, the main reason for questioning it though is because it effectively 'breaks' a macOS feature but equally, the benefits of the lock file likely outweigh that feature and it is an obscure scenario, though I have had cause to rename folders in macOS when files are open but it's very rare...

 

36 minutes ago, walt.farrell said:

It will be interesting to see what the Serif staff think.

That's my hope too...

[walt.farrell]

3 minutes ago, Hangman said:

the main reason for questioning it though is because it effectively 'breaks' a macOS feature

It breaks a V1 workflow, but I don't agree that it breaks a macOS feature. You were still able to rename the containing folder, after all.

[Hangman]

Just now, walt.farrell said:

It breaks a V1 workflow, but I don't agree that it breaks a macOS feature. You were still able to rename the containing folder, after all.

Fair point well made (as usual)...

[MikeTO]

9 hours ago, walt.farrell said:

The failure to Save seems reasonable to me, and it feels appropriate to suggest Save As instead.

I would also think it reasonable for Edit In to fail, and it's good that it didn't lose the file (as has happened in some scenarios in the past) but there should be a better error message, I think.

I would expect that behaviour on Windows but not on macOS.

[NathanC]

Hi @Hangman,

In V2 I wasn't finding that the app was immediately forcing a 'Save as' following a containing folder rename, this would only occur at the point at which I attempted to save the document, this was just using a basic folder in Documents that contained a few .afdesign files, are you getting this immediately?

22 hours ago, Hangman said:

Folder renaming with open files is allowable on macOS and works without issue in v1 but of course that was before the introduction of lock files

Is this working differently for you in V1? I've gone back to V1 to compare the behaviour on an .afdesign file and the folder rename in V1 works as expected, but attempting to modify and save the file following the folder rename forces a 'Save As' in a similar fashion to V2, albeit without reference to a ~lock file.

 

22 hours ago, Hangman said:

So subsequently the file can't be opened in the other Affinity Apps using Edit in...

This part is now handled better than it was in V1, if you were to open a file > rename the folder which contains the file > Try to use the 'Edit in' function the app prompts the below error for me and forces a document closure. In V2 you're able to still stay in the app and also 'Save as'  Although I agree that the error that prompts in V2 could stand to be a little clearer.

I do think how it's currently handled by prompting the 'Save as' option is expected when you attempt to save the file, and while looking into this I was also interested to see what PS and AI do with their respective formats, which I found following a folder rename and subsequent save both failed on the file could not be found or considered it 'read only' and forced a save as.

[anto]

Another problem arises when Publisher crashes, for example. If you copy this file to another location, you won't be able to open it, and you'll get a message that the file is being used by another program, even though the program is closed after the crash.

[walt.farrell]

17 minutes ago, anto said:

Another problem arises when Publisher crashes, for example. If you copy this file to another location, you won't be able to open it, and you'll get a message that the file is being used by another program, even though the program is closed after the crash.

I'm not sure I understand that scenario. Did it involve renaming a follder, as Hangman described? And which file did you copy?

 

[Hangman]

1 minute ago, anto said:

Another problem arises when Publisher crashes, for example. If you copy this file to another location, you won't be able to open it, and you'll get a message that the file is being used by another program, even though the program is closed after the crash.

I'm not seeing this but maybe I'm doing something different here...

I'm able to move the file after Publisher crashes and reopen it resulting in a lock file in both locations... If you do see the problem deleting the original lock file should overcome the issue...

[anto]

14 minutes ago, Hangman said:

I'm able to move the file after Publisher crashes and reopen it resulting in a lock file in both locations..

i have got such info

[Hangman]

3 minutes ago, anto said:

i have got such info

What happens in that instance when you delete the lock file, will the file open then...

Don't forget, there is a 5 minute timeout on the lock file after a crash...

[anto]

8 minutes ago, Hangman said:

Don't forget, there is a 5 minute timeout on the lock file after a crash...

I'll try it another time. I didn't know there was a lock file.

[Hangman]

1 minute ago, anto said:

I'll try it another time. I didn't know there was a lock file.

[Hangman]

Hi @NathanC,

I've just retested this in both v1 and v2 and your comments are spot on, apologies for any confusion I was convinced that I had been able to rename a folder in v1 and still save the open file in the renamed folder but I can't replicate that now...

Out of interest, is there any reason why Affinity apps don't follow typical macOS behaviour which do allow both file and folder renaming with open files?

 

[NathanC]

Hi @Hangman

No worries, to be honest i'm not sure (I use both OS's but tend to gravitate towards Windows, where we are not given such luxuries 😅) but based on that it is the standard behaviour on MacOS i'll log an improvement for this file/folder renaming functionality and see what I get back.

[Hangman]

Hi @NathanC,

That's perfect, thanks for logging this as an improvement...

I was curious as to whether this may (or may not) help in situations of possible file corruption and/or 'failed to save' error messages by allowing the problematic file and/or containing folder to be renamed while the file is still open effectively creating a live copy of the original?

[NathanC]

17 hours ago, Hangman said:

I was curious as to whether this may (or may not) help in situations of possible file corruption and/or 'failed to save' error messages by allowing the problematic file and/or containing folder to be renamed while the file is still open effectively creating a live copy of the original?

If I recall correctly while testing the folder rename in V1 I'm pretty sure I ran into a 'Access to the file was lost' at least twice after renaming the folder which forced me to close the doc without me actioning anything within the app, however in V2 I did not encounter this error. It's possible that allowing this may help in certain scenarios as you say.