Program deletes it's own data folder

I have an app that creates it’s own folders to store it’s user personal data files ie. databases, pictures etc. in a subfolder of [USER]\Documents.
For a long time I’ve had the occasional user tell me that after many years of user they have started the program to find all their data has completely disappeared. I have always replied that the program doesn’t delete the files it created even when you uninstall and reinstall and it must be something else eg. they have logged into a different user account, restored Windows to an earlier date, moved their Documents folder location etc.
Then recently, it happened to me. Everything gone! Trouble is the action can’t be easily replicated, it’s so intermittent.
The only thing I can see is that when the program starts it checks to see if the folder exists, if not it creates one.
Pretty standard code but I’m thinking it is creating the folder regardless of whether it exists and therefore destroying all the original contents.

if userFolder.Exists = False then userFolder.CreateAsFolder end if

If you search this forum, you will see numerous examples of problems storing an app’s data folder at other than…
SpecialFolder.ApplicationData.Child(“myFolder”).Child(“myFile”)
Disregard that advice at your own risk, as you have apparently found out.

Mac or Windows?

Is it actually creating the data files? Could it be that saving is failing somehow and thus the data isn’t actually being written to disk? Are you using some form of atomic saving? Where you write the data to a temporary file, and only upon completion of writing do you then replace the actual file?

Now it sounds like you’re creating what’s called a ShoeBox application, and the correct location for this data was as Roger illustrates. I’m currently fighting with a Mac App Store reviewer as they claim a new rule introduced (which is not in the developer documentation) is that all saved user data needs to use a Save Dialog, and to let the user choose the save location. Which kinda ruins the point of a ShoeBox application, so far my appeal has not yet been answered either.

Oh for crying out loud. How ridiculous. Thanks for fighting that battle, Sam.

[quote=404242:@Roger Clary]If you search this forum, you will see numerous examples of problems storing an app’s data folder at other than…
SpecialFolder.ApplicationData.Child(“myFolder”).Child(“myFile”)
Disregard that advice at your own risk, as you have apparently found out.[/quote]
Oh, I thought it would be in line with the general way Microsoft wants you to organise things. Why is there a Documents folder?
When many Microsoft programs create a document they save to Documents, when they save a pictures they save to the Pictures folder which is a sub-folder of Documents. My video editing program creates new projects by default in Videos, a subfolder of Documents.
When the user chooses to backup their Documents to a removable drive or online everything is saved. If they want to move their program they just copy the programs folder in Documents to move all their data with it.
Application data is by default a hidden folder and isn’t the first place people look for their Documents and pictures. Many don’t even know it’s there. I save user settings etc there but not the end product.
My program launches files through file association so people open their Documents and double click to launch their program.
I think it’s simple and easy for them to understand, why not?
The biggest problem with a SAVE dialog is it will go to the last place they saved. Many don’t read it and just click SAVE. When they open the program they can’t find it because Windows will again default to the last location they opened from.

IMHO, the distinction is between files which your app creates and which it needs to operate, DB’s, Prefs, etc. and files created by the user using your app. The latter should go in documents, but your OP referring to [quote]creates it’s own folders[/quote] led me to believe you were taking about the former.

The program creates charts in the form of HTML, pdf and jpg. It also produces document reports.
The databases the user creates also reside with these things as Microsoft Access stores it’s database in Documents by default. I don’t think this is much different to Excel storing spreadsheets in Documents. Documents has become a universal term for the filing cabinet where you keep your personal stuff not just letters.
It’s not the application’s data it is in widely accepted format which the user can open with any program that suits. I don’t see why would they look in my programs hidden application data folder when they want to find a report or picture my program made.

If Not UserFolder.Exists Then

Basically the same, but in a strange world, who knows ?

Did you find a way to replicate the delete ?

Note to all:
I store data in Documents in an application that is used daily for more than 5 years and (cross fingers) no troubles.

MUST we (all) move that to SpecialFolder.ApplicationData.Child("myFolder").<etc.> ?

Similar: I now store that kind of data in Documents in an application that is used daily for more than 18 years.
I used to use ApplicationData but stopped for the same reasons - the user cannot see the documents, and I WANT them to be able to edit them.

Yes, there are troubles.
On windows, roaming profiles can mean that the documents folder you see doesn’t contain ‘your stuff’ for some reason.
For example , logging in as a different user account means you get a different Documents folder (my app then creates the required default data set, but anything the ‘other user’ has saved in their location is not there)

I’ve had reports that:
‘I don’t HAVE a documents folder’ (network machines where draconian IT departments have gone on a ‘deny everything’ spree)
‘Windows hasn’t allowed your app to create anything in that folder’ (Virus checkers? Permissions? Who knows… to fix that one I have had to send over a zipped copy of the folder and unpack by hand)

Then there is the classic ‘accidentally dragged a folder inside another folder while using File Explorer’ - that looks like something has been deleted, whereas it is just hidden in another place.
Then there’s ownership permissions - the folder ‘appears’ to be owned by another user, so you cannot access it without taking ownership.

On Mac I have seen the subfolder of documents get similar permissions problems.

BUT:
I just tested folderitem.createasfolder
If the folder exists, it doesn’t delete it and create an empty one (at least in Xojo2018 on the mac)
In fact, it doesn’t even error (which it should IMO)

I add a MenuItem that displays a window (with a bunch of Canvas with folder Icons) my man there can use to click and open different folders from the Documents:<app_name>: just to be sure “he” goes to the right location and not elsewhere on his hard disk…

[quote=404273:@Jeff Tullin]Yes, there are troubles.
On windows, roaming profiles can mean that the documents folder you see doesn’t contain ‘your stuff’ for some reason.[/quote]
Not pointing to the true Documents folder may be the key to the problem. I’m looking into this because it would cause userFolder.Exists to return false.
If you add other folders to your Documents library Windows 10 get’s confused. Sometimes I open my Documents from the start menu and it is completely empty. Open later and everything is there.
Also Windows 10 did have serious permission problems in the early editions. You couldn’t save to your own Documents or Pictures folder because you didn’t have permission. (Google it)
Fixed with later updates.

I didn’t remember but this is actually the term Apple uses:
https://developer.apple.com/library/archive/documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html

(search for “shoebox”)

From that same (official) document:

So, why require now to manually select the location? (traditionally you were allowed to let the user change the default location if the user wanted, but weren’t required -OR EXPECTED- to ask for it).