[scribus-dev] Collect 4 Output file permissions and behaviour

[Mark Heieis]

Hi Craig,

I think I narrowed down the errant behaviour.

First off, the patch code does work. Starting from opening a file and 
then calling c4o worked well. All of the c4o documents maintained the 
original src file permissions. So I think that solves the file 
permissions problem.

So that leaves the errant behaviour and why. The behaviour I saw was due 
to me deleting files in the destination folder mid-stream while 
experimenting with scribus/c4o in debug mode. In playing with the code 
and scribus, I didn't notice that once c4o was executed, the scribus 
document context changed from the document source directory to the c4o 
output directory. So what was happening when I re-executed c4o, scribus 
used the c4o destination as its source, which of course failed when I 
deleted the image directory or images files (ie no "source" files). (You 
can see this context change in the title bar for the active document)

The question is: should the document directory context be changing when 
c4o is executed? In my mind, the c4o output shouldn't be used for 
document changes. What is the expectation? If I was making changes, I'd 
want them in my source files and then re-execute c4o as needed, 
otherwise the chance of losing edits would be great.

Regards,


mrh.


On 2013-12-11 07:05, Mark Heieis wrote:
> Hi Craig,
>
> I was wondering about copyFileAtomic() after I sent the email. I'm 
> using Fedora 19. I tested with a small, independent code fragment. The 
> behaviour of it mimicked what I saw happen with collect4output. I'll 
> investigate some more and respond off list.
>
> Cheers.
>
> mrh.
>
> On 2013-12-11 03:29, Craig Bradney wrote:
>>
>>
>>
>>> On 11 Dec 2013, at 4:18, Mark Heieis <mheieis at alois.ca> wrote:
>>>
>>> Hi Craig,
>>>
>>> I dug a little deeper and this is what I found: If the destination 
>>> file(s) already exist, then setPermissions() will succeed. It 
>>> appears, however, if they don't exist, setPermissions() will fail.
>>>
>>> In the patch, it doesn't look like the output files have actually 
>>> been physically created when setPermissions() is called, only the 
>>> file descriptors have.
>>>
>>>
>> Hi
>>
>> Well we need to check this as the copyFileAtomic code has already run 
>> and the permissions copy runs between the old and new file. What is 
>> are you on? I'm testing this on OSX.
>>
>> Thanks
>> Craig
>> ___
>> Scribus Mailing List: scribus at lists.scribus.net
>> Edit your options or unsubscribe:
>> http://lists.scribus.net/mailman/listinfo/scribus
>> See also:
>> http://wiki.scribus.net
>> http://forums.scribus.net
>