FolderItem.Exists

I’m trying to get a FolderItem on Windows with

GetFolderItem("\\\\myserver\\sharepoint", FolderItem.PathTypeNative)

the item exists, actually is a Windows share and I have no permission to modify it, but I just need to see if it exists.
The code above get back a valid FolderItem instance, but the Exists property is false.

The same happen for files inside this folder. Can get and read the files, but they are marked as not existing from FolderItem.

Is this a bug or may be something else?

Looks like this is a known issue

feedback://showreport?report_id=22987

It’s already been tagged as verified though.

search feedback for ‘FolderItem Exists’, and you’ll find: feedback://showreport?report_id=22987
note that you also can’t rely on: FolderItem.IsReadable/IsWriteable
i’ve seen some windows-environments with some ‘more complex’ file permissions structures (Active Directory, groups-in-groups, …can’t remember exactly…) where you can hardly rely any of these properties…
so all i can recommend is that you try to read the file (write a temporary file to the folder.) if success - you are sure you can read/write.

This thing is still creating me a lot of problems.
Anyone know a workaround to this problem?

Have you tried creating a folderitem in the share? It should be nil if the share doesn’t exist. If not, try writing to it.

Seems working, thanks, but I’m not sure if it’s reliable.
In one of my tests I got a valid folderitem, even if the share was not existing.
If I can reproduce this, have to test what happen trying to open a binaryStream and write to it.

[quote=67246:@Massimo Valle]This thing is still creating me a lot of problems.
Anyone know a workaround to this problem?[/quote]

I understand you have no permission to write. But what if you simply try to read a few bytes ? If error you catch, then the file does not exist. Just a thought.

This is what I’ve resorted to on Windows specifically, but I’ve also left it in for Linux and OS X since it’s a “second set of eyes” on the file state. This also catches a permissions setting that used to be missed on Linux back in 2008 or so that I’ve just left in place.

I will try, thanks.
But then why Xojo don’t do this instead?

Just a guess here, but I would suspect that the Xojo routines depend on the reliability of the underlying OSes file processing. I’ve run into share access issues on Windows in VC++ using MS’ own APIs.