On Thu, Jan 19, 2012 at 10:42:28PM +0100, ext David Faure wrote:
> Ah, but my "separate class" initial idea was the KDE/QtCreator idea, i.e. a
> class that isn't a QFile. So deriving from QFile is a new idea :)
>
well, creator's savefile is derived from qtemporaryfile, which makes the
implementat
On Friday 06 January 2012 19:09:26 Thiago Macieira wrote:
> On Friday, 6 de January de 2012 21.38.19, David Faure wrote:
> > > The first solution doesn't look nice. It would have to fail opening
> > > completely.
> >
> > Well, this is just like using ReadOnly | Truncate, for instance. These are
>
On Tuesday 10 January 2012 13:43:29 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote:
> On 6. jan. 2012, at 21.27, ext David Faure wrote:
> > On Friday 06 January 2012 11:41:05 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote:
> >> I don't support putting this in QFile as has been suggested as, from my
> >> experience
On Tue, Jan 10, 2012 at 02:08:38PM +0100, João Abecasis wrote:
> On 10. jan. 2012, at 13.31, ext Oswald Buddenhagen wrote:
> > On Tue, Jan 10, 2012 at 01:00:42PM +0100, ext João Abecasis wrote:
> >> It is not appropriate to tag an atomically-replace-previous-version on
> >> to the close()
> >
> >
On 10. jan. 2012, at 13.31, ext Oswald Buddenhagen wrote:
> On Tue, Jan 10, 2012 at 01:00:42PM +0100, ext João Abecasis wrote:
>> It is not appropriate to tag an atomically-replace-previous-version on
>> to the close()
>
> you don't provide any supporting evidence for that pov, though.
Because
On 6. jan. 2012, at 21.27, ext David Faure wrote:
> On Friday 06 January 2012 11:41:05 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote:
>> I don't support putting this in QFile as has been suggested as, from my
>> experience with it, this will open a can of worms in maintenance and
>> subtle issues croppin
On Tue, Jan 10, 2012 at 01:00:42PM +0100, ext João Abecasis wrote:
> It is not appropriate to tag an atomically-replace-previous-version on
> to the close()
>
you don't provide any supporting evidence for that pov, though.
> and normal clean up that the destructor does.
>
that i agree with.
> >
On 6. jan. 2012, at 22.09, ext Thiago Macieira wrote:
>> Why would this be better? It can't be "because it's not clear which file
>> some methods should work on" (Joao's argument), since it would still have
>> all the QFile methods. It can't be because we need additional API compared
>> to QFile,
On 6. jan. 2012, at 22.13, ext Thiago Macieira wrote:
> On Friday, 6 de January de 2012 21.27.20, David Faure wrote:
>> Exception handling is a new argument though. But doesn't the current QFile
>> have the exact same issue then? You start writing, throw an exception, dtor
>> calls close, there
On 10. jan. 2012, at 02.39, ext craig.sc...@csiro.au wrote:
> On 09/01/2012, at 10:14 PM, Oswald Buddenhagen wrote:
>> On Fri, Jan 06, 2012 at 07:13:00PM -0200, ext Thiago Macieira wrote:
>>> On Friday, 6 de January de 2012 21.27.20, David Faure wrote:
Exception handling is a new argument tho
On 09/01/2012, at 10:14 PM, Oswald Buddenhagen wrote:
> On Fri, Jan 06, 2012 at 07:13:00PM -0200, ext Thiago Macieira wrote:
>> On Friday, 6 de January de 2012 21.27.20, David Faure wrote:
>>> Exception handling is a new argument though. But doesn't the current QFile
>>> have the exact same issu
On Fri, Jan 06, 2012 at 07:13:00PM -0200, ext Thiago Macieira wrote:
> On Friday, 6 de January de 2012 21.27.20, David Faure wrote:
> > Exception handling is a new argument though. But doesn't the current QFile
> > have the exact same issue then? You start writing, throw an exception, dtor
> > ca
On Fri, Jan 06, 2012 at 07:04:56PM -0200, ext Thiago Macieira wrote:
> Moreover, filesystems on Linux (at least) are tuned so that, if the renaming
> is
> recorded, the data was too. There was an issue with early ext4 that those
> were
> not synchronised: the writing of the rename happened up t
On Saturday, 7 de January de 2012 16.56.19, Stephen Kelly wrote:
> On Friday, January 06, 2012 19:09:26 Thiago Macieira wrote:
> > If the method accepted a QFile pointer before, then a class derived from
> > QFile will automatically downcast to the type.
>
> This could be a downcast-vs-upcast defi
On Friday, January 06, 2012 19:09:26 Thiago Macieira wrote:
> If the method accepted a QFile pointer before, then a class derived from
> QFile will automatically downcast to the type.
This could be a downcast-vs-upcast definition mismatch in your understandings?
I think David is saying that a me
On Friday, 6 de January de 2012 21.27.20, David Faure wrote:
> Exception handling is a new argument though. But doesn't the current QFile
> have the exact same issue then? You start writing, throw an exception, dtor
> calls close, there you go. The use of an internal temporary file doesn't
> change
On Friday, 6 de January de 2012 21.38.19, David Faure wrote:
> > The first solution doesn't look nice. It would have to fail opening
> > completely.
>
> Well, this is just like using ReadOnly | Truncate, for instance. These are
> incompatible. What happens? Truncate will be ignored, and you don't e
On Friday, 6 de January de 2012 17.22.18, Artur Souza (MoRpHeUz) wrote:
> > If the app crashes at any other point, i.e. after close(), and then the
> > 'target' file is the one you want to open anyway.
> >
> > The saving happens into the temp file. So there is nothing "to restore" in
> > case of a
On Fri, Jan 6, 2012 at 9:38 PM, David Faure wrote:
> It could even add an unnecessary need for casting, I could imagine: a public
> method takes a QFile, then you realize it should handle disk-full situations
> better, so you pass it a QSaveFile and you have to downcast it internally to
> call rol
On Friday 06 January 2012 17:11:29 Thiago Macieira wrote:
> On Friday, 6 de January de 2012 18.34.21, David Faure wrote:
> > On Thursday 05 January 2012 22:38:37 Thiago Macieira wrote:
> > > What happens if you open the file in read or read-write mode while the
> > > flag
> > > is on?
> >
> > I th
On Friday 06 January 2012 11:41:05 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote:
> > Solution 2: how about making this functionality part of QFile itself?
> > No need to "port to another class" anymore, just enable the safety
> > feature by calling file.setUseTemporaryFile(true). This is what I've
> > s
On Fri, Jan 6, 2012 at 4:39 PM, David Faure wrote:
> If the app crashes between open and close, i.e. in the middle of the writing
> -- then what you want to open in your text editor, is the existing untouched
> (older) version of the file, NOT the half-written temp file.
"I'm sold" :)
> If the a
On Friday 06 January 2012 14:43:30 Artur Souza (MoRpHeUz) wrote:
> On Fri, Jan 6, 2012 at 2:36 PM, David Faure wrote:
> > No, no, the whole idea of this feature is not to use the temp file as a
> > backup. If the app crashes, you lose your partially-writen temporary
> > file. That's fine, it was p
On Friday, 6 de January de 2012 18.34.21, David Faure wrote:
> On Thursday 05 January 2012 22:38:37 Thiago Macieira wrote:
> > What happens if you open the file in read or read-write mode while the
> > flag
> > is on?
>
> I think that should just ignore the request for a temp file, since it cannot
On Fri, Jan 6, 2012 at 2:36 PM, David Faure wrote:
> No, no, the whole idea of this feature is not to use the temp file as a
> backup.
> If the app crashes, you lose your partially-writen temporary file.
> That's fine, it was partial anyway, why would you want to use it?
>
> I think you're confus
On Friday 06 January 2012 09:50:14 Artur Souza (MoRpHeUz) wrote:
> On Thu, Jan 5, 2012 at 8:32 PM, David Faure wrote:
> > Now there's just one question remaining: even if the rule is that all
> > operations apply to the temp file, between open and close... what should
> > QFile::fileName() return?
On Thursday 05 January 2012 22:38:37 Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 22.48.32, David Faure wrote:
> > Solution 2: how about making this functionality part of QFile itself?
> > No need to "port to another class" anymore, just enable the safety feature
> > by calling file.
On Fri, Jan 06, 2012 at 12:53:27PM +, ext shane.kea...@accenture.com wrote:
> > the mode is inherently incompatible with read-write without truncate.
>
> Not necessarily, it could make sense to copy the original file to the
> temporary file in this case.
>
i don't think we want that much abst
> On Thu, Jan 05, 2012 at 10:38:37PM -0200, ext Thiago Macieira wrote:
> > What happens if you open the file in read or read-write mode while the
> > flag is on?
> >
> for read-only this is obviously meaningless.
> the mode is inherently incompatible with read-write without truncate.
> in read-writ
On Thu, Jan 5, 2012 at 8:32 PM, David Faure wrote:
> Now there's just one question remaining: even if the rule is that all
> operations apply to the temp file, between open and close... what should
> QFile::fileName() return? The temp file name, to obey that rule, or the target
> file name, for sy
On Fri, Jan 06, 2012 at 09:59:10AM +0100, ext Eirik Aavitsland wrote:
> On 01/06/2012 12:45 AM, ext craig.sc...@csiro.au wrote:
> > The temporary file is meant to be an updated version of the real
> > target. If you want to call rename(), you really should first commit
> > any changes and then rena
David Faure wrote:
> A very common issue with writing over an existing file, is that in
> case of problem in the middle of the writing operation (disk full,
> application crash, power failure...) the existing file will be lost.
> If it contained your thesis, you might be a bit angry at the Qt
> app
On 01/06/2012 12:45 AM, ext craig.sc...@csiro.au wrote:
>
> If the rule is that all operations apply to the temp file rather than
> the originally named file, this will potentially change the behaviour
> of existing functions that accept a QFile as a parameter. I'm leaning
> more towards having rem
On Thursday, 5 de January de 2012 22.48.32, David Faure wrote:
> Solution 2: how about making this functionality part of QFile itself?
> No need to "port to another class" anymore, just enable the safety feature
> by calling file.setUseTemporaryFile(true).
What happens if you open the file in rea
On 06/01/2012, at 10:32 AM, David Faure wrote:
> On Friday 06 January 2012 10:24:04 craig.sc...@csiro.au wrote:
>> I like the idea that if nothing goes wrong, then close() commits the changes
>> (ie renames the temporary file to the real file name). It makes using a
>> QFile with this feature ver
On Friday 06 January 2012 10:24:04 craig.sc...@csiro.au wrote:
> I like the idea that if nothing goes wrong, then close() commits the changes
> (ie renames the temporary file to the real file name). It makes using a
> QFile with this feature very transparent and means that functions that
> accept a
On 06/01/2012, at 10:13 AM, David Faure wrote:
> On Thursday 05 January 2012 22:21:54 Richard Moore wrote:
>> 2012/1/5 David Faure :
>>> Solution 2: how about making this functionality part of QFile itself?
>>> No need to "port to another class" anymore, just enable the safety feature
>>> by call
On Thursday 05 January 2012 22:21:54 Richard Moore wrote:
> 2012/1/5 David Faure :
> > Solution 2: how about making this functionality part of QFile itself?
> > No need to "port to another class" anymore, just enable the safety feature
> > by calling file.setUseTemporaryFile(true).
> > This is what
2012/1/5 David Faure :
> Solution 2: how about making this functionality part of QFile itself?
> No need to "port to another class" anymore, just enable the safety feature by
> calling file.setUseTemporaryFile(true).
> This is what I've started doing in the attached patch, but I'd like to gather
>
2012/1/5 David Faure :
> Oswald suggested doing that in close()/remove() directly, and getting rid of
> commit()/rollback(). Opinions?
I tend to agree with Oswald here.
Cheers,
--
---
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Te
A very common issue with writing over an existing file, is that in case of
problem in the middle of the writing operation (disk full, application crash,
power failure...) the existing file will be lost. If it contained your thesis,
you might be a bit angry at the Qt application that did that.
T
41 matches
Mail list logo
