v1105 Open .afpub error: "File is already open in another application"

[thomaso]

Any chance to get this fixed? This .afpub was created 2 days ago, saved and closed. Today it refuses to open with the error "File is already open in another application". … No chance, even if I close every other application + relaunch APub:

As a possible workaround I copied this .afpub in the macOS Finder. But now "The file type is not supported."
How does this work? Where can I fix this? It does not seem to be caused by a leftover in my APub library folder – but where else?

I one of you able to open this file and save it with Save As with a different name + upload again?

v1105 Grayscale.afpub

[carl123]

Tried to open but got a message which I've only seen before when trying to open a recovery file. But I don't use Macs so could be different

If this was on Windows I would reboot my PC to cure the in-use problem and then make sure I was opening the correct file

[thomaso]

Thanks carl123. – After rebooting the mac, APub now reports your message, too.

Definitely strange since this file neither got opened in another application nor has ever been used / touched by another application (neither linked nor embedded).

I wonder how come that APub creates 3 different messages for a file with identical, unchanged contents?

If a reboot matters, where does APub store such confused and confusing info if not in my APub user library folder?

[walt.farrell]

47 minutes ago, thomaso said:

Definitely strange since this file neither got opened in another application nor has ever been used / touched by another application (neither linked nor embedded).

"Linked" in this case is not referring to Placed files. It's referring to trying to open an Autosave file that contains only part of the data.

But that message doesn't make any sense unless you found a .autosave file and renamed it to have a different extension.

[thomaso]

1 minute ago, walt.farrell said:

But that message doesn't make any sense unless you found a .autosave file and renamed it to have a different extension.

No, I did not. I had no crash with this document before that might have left an autosave file. Also, after getting this message first I closed all two other open documents & checked the empty autosave folder before I tried to open this .afpub again.

Aside that, what causes 3 different messages at all? I really would like to understand the process which makes APub display different error messages for 1 certain .afpub. And where data get stored which seem to make a mac reboot causing a different message. I can imagine that a file transfer via a forums upload may cause a different message – but why a pure local .afpub?

[carl123]

1 minute ago, thomaso said:

I can imagine that a file transfer via a forums upload may cause a different message – but why a pure local .afpub?

When you copied the original file to a new file the original message....

"This file is already open in another application"

...would not be relevant to the new file

Hence the 2nd (different) error message

[thomaso]

Agree, but then I would expect the error of the renamed copy ('Filetype not supported') also appear when you opened the downloaded copy (though it was not renamed). The fact that these two copies create different error messages confuses me, too.

If I now download this .afpub from the forum I still get the 'File linked, parent not found'. – Same if I rename it and/or copy + rename it.

[Dan C]

Thanks for your file @thomaso and I'm sorry to see you're having trouble here.

I've downloaded and checked this file in a HEX editor, which seems to show a considerable 'chunk' of the file has been lost / corrupted -

17 hours ago, thomaso said:

what causes 3 different messages at all? I really would like to understand the process which makes APub display different error messages for 1 certain .afpub.

With so much missing data, I would not be surprised if the Affinity app is simply confused when opening this document and it hits multiple thresholds for error messages, then produces the first one the app triggered - though this is an assumption.

19 hours ago, thomaso said:

it refuses to open with the error "File is already open in another application". …

I've seen this before if the file is in a Cloud / 'synced' location, as the file can be 'in use' by the cloud service when Affinity attempts to open it, causing the conflict. Is this in a 'synced' location please?

[thomaso]

1 hour ago, Dan C said:

I've seen this before if the file is in a Cloud / 'synced' location, as the file can be 'in use' by the cloud service when Affinity attempts to open it, causing the conflict. Is this in a 'synced' location please?

No, I don't use any external volume for working files, all are stored on the local build in SSD (external disks only for backups).

In case you want to investigate this further: Here this file from a backup. As far I see it doesn't differ from my last version, though its file size is 100 kB less.

v1105 Grayscale backup 220728-1121.afpub

1 hour ago, Dan C said:

a considerable 'chunk' of the file has been lost / corrupted

Since the backup file size is smaller but the layout appears to contain everything I wonder even more what would be lost (~ missing?) in the corrupted .afpub? Or can lost also mean it gets written but without the common / a useful structure?

[Dan C]

Thanks for confirming - I'm logging these files with our developers now, however I cannot guarantee I will receive a direct response as unrecoverable files (with missing HEX data) are investigated 'in bulk' to help reduce the chances of this happening in a future update, rather than individually assessed to provide a potential explainable 'cause' for each file.

1 hour ago, thomaso said:

Since the backup file size is smaller but the layout appears to contain everything I wonder even more what would be lost (~ missing?) in the corrupted .afpub? Or can lost also mean it gets written but without the common / a useful structure?

As I understand it, this missing data can be structure based, for example I've seen files become corrupted due to missing file signatures in the header, or incorrect CRC check values. As there is such a small difference in file size, I suspect it will be something similar to this, though I have also seen very minor corruptions that means the compressed document data cannot be decompressed, indicating the data itself is present, but cannot be accessed, so this is also a possibility.

My apologies I cannot be more specific at this time!

[thomaso]

35 minutes ago, Dan C said:

Thanks for confirming - I'm logging these files with our developers now, however I cannot guarantee

Thank you, too. I don't need a reconstruction since I used a backup meanwhile. So there is no need to provide a fixed version to me.

I am rather interested in understanding what is going on in particular, respectively whether / when / how such issues can either get avoided or possibly get fixed by users.

Concerning possible fix: Is it generally possible for us users to repair a broken or incomplete header with any common text or hex editor (if we would know the missing parts) and create a proper .afpub document just by maintaining this suffix? (*) – Or would a fix require special decoding / coding / conversion tools?
(* as possible for instance with .idml)

[Dan C]

No problem at all, I've informed the developers a fix isn't required as I've attached both the working and corrupted file to the report - but I've also requested more information to try and better understand the cause of this.

16 minutes ago, thomaso said:

Concerning possible fix: Is it generally possible for us users to repair a broken or incomplete header with any common text or hex editor (if we would know the missing parts) and create a proper .afpub document just by maintaining this suffix? (*) – Or would a fix require special decoding / coding / conversion tools?

I'm almost certain this requires the specific debug build / tools that only our developers with source code access can use to repair these files, but again I'll be sure to double check with the team