FolderItem Annoyances

· Feb 23, 06:46 PM

Suppose you have a FolderItem parent representing a directory, and the directory contains a file named foo.

What would you expect the result of parent.Child(“Foo”) to be when the user executing it lacks execute permission for the directory?

For Mac OS X, at least, the answer is that parent.Child(“Foo”) returns a non-nil FolderItem whose Exists property is false. I think that the result should be nil; indeed, parent.Item(1) does return nil.

More perplexing, though, is the LastErrorCode property. In both cases, I would expect parent.LastErrorCode to return error -5000: “User does not have the correct access to the file”, or some error code other than 0. What happens is that parent.LastErrorCode = 0 in both cases. In the case of FolderItem.Child, parent.Child(“Foo”).LastErrorCode returns -5000. I am not fond of the LastErrorCode approach to announcing errors, but since it is there, it seems reasonable to expect that when I call an object method, the associated error code be found in the same object.

This is, I suppose, a minor annoyance, but I have found several problems with FolderItems in recent months, including one that corrupted the file system in Linux, requiring me to spend hours rebuilding some systems. And there are other problems. For example, it is not clear to me that it is possible to create files securely in REALbasic. This is a real problem for server development. I’m beginning to wonder if I wouldn’t be better off writing some FolderItem replacement classes.

---

Comment

  1. Well, what can I say – I agree with you. It appears the the results make it hard to decipher what is going on. If you get a FolderItems with Exists = false, and no Errocode, then you’d expect that you could create the folder there. But that’ll fail as well, which leaves you in a odd state, I guess.
    At least, these things need proper documentation. If your wiki will doc that well at least, then there’s hope that we might be able to master this some day :)
    Of course, it also needs a commitment from the RS dev team to acknowledge this problem and to make sure they do not invert the behaviour later to cause new problems.
    Well, maybe a new FolderItem class is indeed the best, with documented and predictable behaviour, because it’s usually impossible to get such acknowledgements from RS. Which is the source of many problems for us.

    — Thomas Tempelmann · Feb 23, 08:53 PM · #

  2. If I have a file in a folder, and I don’t have the correct rights to access that folder, then I’d sorta expect either of the following :
    1. We get a non-nil folderitem combined with folderitem exists being true, because the files does exist, but we don’t have rights to it. The lasterrorcode would be -5000 since we don’t have correct access to the file. This looks like a no-no due to the fact that we are not even allowed to look in the folder, and letting us know the file exists, would be a violation of our rights.
    2. We get a nil folderitem combined with folderitem exist being false, because due to our right on the folder we can’t even see if the file exists or not.

    Nr 2 seems to be the correct way of handling it, since Nr 1 is a violation of our rights.
    In case 2 it wouldn’t make sense to have a lasterrorcode on the folderitem, since we wouldn’t know if it existed or not (although i guess it wouldn’t hurt to duplicate it here, so we can test on the folderitem we tried to access, instead of having to test the parent seperately, which is probably why RB gives us the error on this level). The access to our requested folderitem would have been blocked at the parentlevel due to our accessrights, so since the error was trigered at this level, I’d expect the lasterrorcode on the parent to reflect the errorcode at the lower level, so it would have to be -5000 as well, instead of 0, even though we never really requested anything of the parent in our code. It just seems inconsistent to have our access blocked at the parentlevel (triggering an errorcode), but not have it reflected in the lasterrorcode of the parent.

    — Dirk Cleenwerck · Feb 25, 04:39 AM · #

Textile Help