[Save Failed because ownership of the file could not be verified]

5 hours ago, R C-R said:

When it is operating normally, there is no reason to retain a recovery file after the document is closed -- on a close or quit, users are given the opportunity to save any unsaved changes or discard them, just like with most other apps. It is important to discard the recovery files because otherwise they would just keep using progressively more disk space.

I was referring specifically to the situation when Affinity can't save (due to remote disk communication issue) and it closes the document on purpose (that's not a crash, is a deliberate command). So, before closing the document, Affinity could simply make a recovery file with everything that hasn't been saved yet and then close. I really can't see what is the issue here.
But instead, as it is now, AF Photo will forcibly close the document and any unsaved edits are gone... sad, very sad.

[How to "release" an element from a page, that has a Master Page applied?]

6 minutes ago, fde101 said:

That is the problem.

The current version, in which that feature was added, is .221.

I didn't get any notification for update and when trying to download it, the file received is still 206. Could you please provide a download link?

Thank you.

@fde101 nvm, I found a link on the forum. Thanks for letting me know about the new version!

[Save Failed because ownership of the file could not be verified]

15 minutes ago, R C-R said:

• File Recovery Interval—sets the interval for saving temporary data for currently open documents, allowing a document restore to be offered at startup if the app develops a fault.

Great feature! Maybe there should be another flag added to this function: when an error happens and Affinity can't perform a normal save... I understand that in the event of a crash, it can't operate because.. it crashed, but when the software is operating normally, I don't understand why it doesn't perform a quick recovery save before shutting down.

[How to "release" an element from a page, that has a Master Page applied?]

@fde101

Right-Clicking on that group of layers, on my "normal" page, shows the following menu (see attached):

AF Publisher Version: 1.7.0.206

if yours looks different, kindly please share a screenshot.

[How to "release" an element from a page, that has a Master Page applied?]

@dutchshader did you manage to find it? If so, do you mind attaching a screenshot? I can't seem to find those options.

Thanks.

[How to "release" an element from a page, that has a Master Page applied?]

I have a Master Page with a text placeholder and I want to have a unique text on each page where that specific placeholder is.
The issue is that the text is between two layers, so if I take the text out of the Master Page Group, (which has been created in page's layers when I applied the master page), the text won't be between those two layers anymore (it has to be between the layers, as the layers do some blending).

So, I would like to be able to edit my text field on every page, but to not affect the Master Page. In Illustrator is possible to "release" a field so it can be edited independently from the Master Page.

Any suggestions?

[Save Failed because ownership of the file could not be verified]

1 minute ago, carl123 said:

Be careful what you wish for.  Last time I complained about something I found a horse's head on my doorstep the next morning.

Coincidence? Maybe, but Nottingham is not that far from where I live.

guess you're right... plus this guys have all our bank account details too...
Don't you suddenly start feeling oppressed? :))

[Purple contour line around text, how to disable it?]

I noticed the objects in Publisher are all surrounded with a purple outline, including text.

For text this is really annoying as I can't clearly see the fill color and asses that against the document (visual contrast, aesthetics, etc). Is it any way to disable the purple outline? The outline is not some effect applied to the text, it comes from the way Affinity is displaying the elements. I also have an image imported in Publisher which has the same purple outline.

- see attached

[Save Failed because ownership of the file could not be verified]

7 hours ago, R C-R said:

Keep in mind that Affinity needs read access to the file for as long as it is open -- it is not just about saving/writing back to it.

I understand that, but what puzzles me is that I was able to work just fine all along and edit my work, until I decided to save... when it closed. And it didn't happen once, it was repetitive, at least 3 times it happened until I decided to write on this forum.

So, if Affinity needs continuous access, why it was no warning and I was allowed to do my work all along? And why it only happened when I tried to save? Also, on opening, there was a recovery dialog which helped me recover a part of my edits, but not all of them (which is weird also, why AF Photo won't save a temp recovery data when such situation happens).

From all talks on this subject, I still see no reason for the following:

• Why Affinity does not give any option for the user to take action, but instead just informs the user about the unavoidable and then closes (don't you find that rude?)
• Why Affinity has to close the document and there is no better solution, like automatic check of connection, and/or even allowing the user to manually re-select the path to file?
• Why Affinity doesn't save the changes until the last one locally (in a temp file), so they can be recovered next time when the file is being open?
   

For me, it all looks like Affinity didn't manage this aspect very well and it would be in their best interest to show their presence here, to let us know they are hearing us and they will take proper action in order to improve user experience on this matter (and not only on this one).

[Save Failed because ownership of the file could not be verified]

17 minutes ago, R C-R said:

As for other brief interruptions, say those that last for no more than a second or two, I would be surprised if the app did not already have a built-in delay before deciding the connection was lost. If not, it should be simple enough to build that into the app.

Surprisingly, it seems is not. My issue while saving on my pCloud virtual drive confirmed it: whilst Affinity Photo was NOT able to save, I had no problem opening the drive and interacting with the files there. So, the storage was available, but for some reason Affinity could not access it.
What I can assume are 2 things:

1. pCloud is "locking" the file while sending it to the cloud server, so Affinity "thought" it cannot be overwritten/saved.

2. there was a short intrerruption at some point and Affinity did not check again

 

@R C-R I understand your point with cached copies, indeed, too many variables and too many complications in too many scenarios. Most probably this wouldn't be the desired solution.
Perhaps then making sure the connection is re-checked, or allowing the user to select the path to the file (in case Affinity can't automatically find it for some reason), and also if possible to save the modifications so they can be recovered.

[Save Failed because ownership of the file could not be verified]

1 hour ago, R C-R said:

No, the point here is how to do that, considering all that is involved, including that for performance & other reasons all of a document file is not loaded into working memory at the same time or into local temp files.

You keep assuming that either it is all loaded at once or that there would be no significant downside in doing so. Neither is true.

Guys, this debate became way too generic. There are two types of interruptions: short (milliseconds - seconds) and long (minutes or even permanent). Two different approaches for two different situations:

• if interruption is short, that means is most probably "sleeping" and it needed a wake-up signal, or it was a short network drop, or something else. But this also means is back in no time. So, after the first failed attempt, the software should warn the user, WITHOUT CLOSING THE DOCUMENT and the user can check the connection of the drive (in explorer, for example) and then try again to save.
• if interruption is long or permanent (someone simply unplugged the drive, or internet is down), there isn't much to do. Obviously the document has to be closed, but maybe a better recovery system could be implemented so all tools and operations can be recovered since the last successful save on the disk.

Now, as long as there isn't any "observer" or "listener" to check connection continuously, I see no reason why there would be any negative impact in performance. Just don't close the document until the user performs another attempt to save. Keep everything on stand-by and there is a very big chance that the connection will be re-established with the help of the user. I really don't see where is the issue here, conceptually speaking.

Also, having a cached copy locally would be a safety measure, a redundancy point. Yes, more space occupied on the local disk... and I see no problem with that. The storage media is meant to be used. I'd welcome a setting in Affinity to allow me to decide on which drive to create a "cached copy" of the current documents. I'd be happy to reserve ~10GB or so for that, when Affinity software is open, just to make sure my files are safe. Of course, there are issues here: what if you have Photo, Designer and Publisher open at the same time? Well, whoever wants to do graphics they usually invest in a decent machine with decent storage... there has to be a compromise anywhere.

[Save Failed because ownership of the file could not be verified]

2 minutes ago, carl123 said:

And a proper fix would...fix

From what I see here, people are debating a lot in terms of fixing... opinions are strong on both sides.
It looks very much like Brexit ... to make a reference to your signature :))))) ... so, we'll wait and see. In the meantime, I'll hire an Egyptian Scribe to sync my files every time.

[Save Failed because ownership of the file could not be verified]

Just now, carl123 said:

That's a bit like having a car that warns you every time you are about to join the motorway/highway that it might unexpectedly crash.

Not what you would want to hear or have to make a decision about

Or is like... windows popping-up the UAC warning... bit annoying at times, but extremely useful!
I agree with this: if there isn't any elegant solution to FIX it (fix = make it work as it should), then a warning with the possibility of disabling (don't show it anymore) would be the common sense thing. 
Why? Because many (most) users would expect the software to work with a networked drive, not knowing there might be stops in communication and that might lead to their work being lost. So, a warning would... warn.

[BLUR GRADIENT]

Although this topic seems old, maybe someone would be interested to replicate my method (i'm using it for creating shadows):

☐ Image_to_blur
	⬕ Live Filter - Gaussian Blur (HIGH value) 
	⬛ Live Filter - Gaussian Blur (LOW value)

Apply a gradient masking on the topmost live filter, to reveal the second blur filter applied. 

obs:

* it doesn't matter which filter is on top, as long as you apply the gradient on the topmost one and the direction of the gradient reveals the blur transition in the desired direction

* the Blur Live Filters have to be applied as children to the layer to blur, so they will only affect that one.

 

 

Attached an example of this procedure, along with the complementary layers to cast a shadow.

* for gradient blur, only the info in red boxes is relevant. The gray info is only important for shadow casting.

[Knotty Lasso selections (video included)]

On 1/9/2019 at 10:13 AM, GabrielM said:

Hi @bitey,

Photoshop might have some sort of stabiliser, and also they do not seem to take into account the pixels, and they average your selection based on the pixels AFTER you make the selection. We lock the selection on pixels, so there is no "on the fly smoothing" applied. 

I have moved this to feature requests.

Thanks,

Gabe. 

I noticed the "jaggy effect" on other types of selections, for the same reason of "selection lock on pixels" and it often requires editing of the mask, to remove this irregularity. Smoothing the selection still keeps a very "wavy" line, unless considerable smoothing is being applied, but then the selection gets affected everywhere.
So, this should be improved in a future release.
Thanks for making AF better!

[Make sure the tool cursor is aligned with the affected area (when Perspective Filter applied)]

As stated on this post: 

It seems that when a Perspective Live Filter is applied to an image, the effect of a brush is being applied with an offset dependent on the Perspective Filter. So, the effect and the cursor circle will not be on the same spot.
This issue should be addressed as it's more of a bug than a "by design" feature. Whilst I understand the effect is also being offset, the cursor circle should mark the are where the effect is being applied, because that's the whole point of the circle cursor: to mark the affected area.

[Save Failed because ownership of the file could not be verified]

5 minutes ago, R C-R said:

All things considered, maybe the best solution, workaround, or whatever you want to call it for this is for the Affinity apps to pop up a warning if a user tries to open a file on a network drive, saying that there is a risk of data loss unless the file is copied to a local drive, with an option to do that?

Yes, I can agree on this: a warning would not solve the issue, but make the user aware of the risk before is too late.
But nonetheless, this should be investigated further. I found also another issue here on the forum with a guy saying he can't sync OneDrive after a file has been modified with AF Photo and he has to restart windows in order for the sync to function again. He has posted it recently. So, it might be a shared issue... we'll wait and see.

[Save Failed because ownership of the file could not be verified]

@R C-R Thank you for the comprehensive clarification, this makes perfect sense.

Yet, if the situation is as you say it, then Serif could do a much better job in perfecting how their software works. For start, some of us have machines with A LOT of RAM... I've got only 16GB, but I am sure there are people with 64-128 here. So, those people did not pay for the ram to keep it unused and instead AF Photo to load bits of file from a slow media (hdd, usb, etc).
So, maybe the software should do a dynamic assessment of the available RAM and decide if it loads the file completely in RAM or loads from the disk piece by piece as needed... 
Also, in terms of disk, some people may have a very fast disk (i've got an m.2 pcie ssd and a sata ssd, beside my storage hdd). So, maybe the software should do a cached copy of the file being edited on a disk at user's choice (editable in settings), and to work from there... this way, even in an event of a crash, there would be a second copy to recover from. I don't mind at all using my ssd for caching, even if that "in theory" would shorten the life of the storage. In reality the drive becomes obsolete before it dies, so I would replace it in 4-5 years anyway. But instead I get the speed and the stability.

And when a saving command is being performed, the original file can be rewritten from the cached version, in this way, even if the media can't be accessed for some reason, affinity can try again, offer the user the option to save in a different place and for work it would always have the cached version, so no interruptions here either.

Maybe some of the development members would like to help us here with a bit of insight and/or get inspired from the above.

I'm not a developer, I'm a product designer with basic knowledge of programming, so I'm just seeing this matter from a very general point of view, thus I might misunderstand some aspects, omit some rather crucial details or just point the obvious without noticing. Apologies for any inconvenience.

[Save Failed because ownership of the file could not be verified]

3 hours ago, Dan C said:

Hi derei!

We've seen this error before when using network/external drives and the connection to the drive is temporarily lost whilst working. Our developers are aware of this and are working to fix it, in the meantime we recommend saving locally and then backing up the file, as v_kyr has suggested  

Hi @Dan C and thanks for your response.
As a suggestion for fixing this: DO NOT CLOSE THE DOCUMENT IF THE SAVE FAILS!! Yeah, is quite basic... why "the document must now be closed"? I mean, keep it open and allow the user to save again...
I am sure that your developers are looking into more professional solutions, but until one has been found, NOT Closing the document could be a great workaround... at least we don't lose the work.
As for saving locally and then backing up, whilst this may be the ultimate solution, is not so convenient at times... one might forget to backup, or may end up with two different versions on two different places due human error, etc... the scribes in Ancient Egypt were manually duplicating papyrus documents, because they didn't know how to make CPU chips with all that silicon laying around. I'm hoping to not get there again.

[Save Failed because ownership of the file could not be verified]

1 hour ago, v_kyr said:

Probably the saving to the virtual drive doesn't always work in a graceful manner here. Thus you better save locally and transfer the file later via the desktop file manager (Explorer) or the like.

So you think it might be the pCloud app causing the issue, not the way AF Photo is saving?

[Save Failed because ownership of the file could not be verified]

 you loose all data since the last autosave due to this issue!!

 

Just got this nasty error when tried to save. Luckily I had a previous save and the file recovered automatically without too much work progress loss.
I'd like to know the cause and what possible steps to take in order to prevent it in the future.

Worth mentioning:

• I am using pCloud, which creates a virtual drive on the computer and I was saving there. Could this cause any issue (the sync process could take ownership of the file temporary or, to lock it in some way)?
• it is the first time when it happened, although i was saving the same for many times.

[How To DRAG Guides in AF Photo?]

Hi @GabrielM and thank you for the quick reply.
I managed to drag the guide thanks to you pointing that small detail (had to enable the rulers)... and also, I was trying to drag with the default tool (the hand), instead of using the MOVE tool.
All set now, thanks.

[How To DRAG Guides in AF Photo?]

Hi everyone, I'm a beginner in working with Affinity, but eager to learn. My question today is about GUIDES. I am aware of the Guide Manager window, when one can add guides and specify preset positions, but what i don't know is how to DRAG a guide with the mouse.
Most of the time, I can't tell where I want the guide to be in pixel, or percent, or mm, but I know where I want it on the image. So, not being able to drag it, to snap it on the edge of an object, or simply to adjust its position on the document is a real pain. All decent software, starting with Photoshop and ending with Inkscape have this feature, so I am sure AF Photo must have it too, I just didn't manage to find how it works.

Kindly please drop me a hint about how to use guides in AF Photo.

Many thanks.