[ATTENTION], "problem" with FolderItem.Exists

[Kevin Windham]

On Feb 21, 2005, at 5:43 AM, jda wrote:

>> I wonder what the rest of the code is. This code doesn't seem to do 
>> anything as far as RB is concerned. The end result is the same and on 
>> one folderitem is created just like the first bit of code. I'm just 
>> wondering if this is really a bug in RB or just an abuse of 
>> folderitem in some way.
>>
>
> Kevin, I have no idea how one can abuse a folderItem. I certainly deny 
> I have ever done it. And rumors to the contrary are not sufficient to 
> convict. At least not again.

I am not trying to convict anyone, just trying to point out what I 
would consider workflow flaw.

>
> There is a bug in RB that causes problems in the following scenario:
>
> 1. Use GetSaveFolderItem to make a folderItem (f) -- it must replace 
> an existing file

FolderItems don't replace anything. It might point to an existing file, 
but it doesn't actually do anything until you call a method on the 
file. So here you have a folderitem that points to an existing file.

> 2. db.Create(f...)

Now you ask Valentina to create a database at a location that is 
occupied by an existing file. To my mind this is a silent error. What 
happens in an app where a user makes a mistake, or it's a simple 
programming error, and Valentina silently replaces a file I wanted?

This is why I think it's an abuse. Valentina should not replace an 
existing file IMO. It should expect the programmer to provide a 
location where a file doesn't exist so that it can create a new one 
there without stomping on the other file.

Of course this is just my opinion, but we can't properly deal with the 
scenario if we don't know about it and for Valentina to silently 
replace the file seems counter to what the create statement's original 
intention was. Create a new file, not delete an existing one.

I appreciate the clarification, and at least now I know to watch out 
for it.


> 3. f points to the file, but f.exists = false (incorrect).
> 4. trouble ensues
>
> Ruslan has found a workaround, which he posted. A safer alternative to 
> reeestablishing the folderItem is:
>
> f = f.parent.child(f.name)
>
> (used immediately after db.Create)
>
> Now f.exists = true
>
> Sooner or later most folks will run into this bug. If you find a 
> better workaround, let us know.

Good catch Jon. I think Ruslan should not wipe out an existing file. I 
think it confuses the intention of create and really the better choice 
here would be to fail and notify the programmer by having create return 
false.

Kevin