The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,732 other followers

Windows applications: storing your data in the correct place (Roaming, Local, LocalLow, not Documents)

Posted by jpluimers on 2022/03/02

This is a follow on the below TomTom HOME complaint: Know where your application should store its data.

I know this can be tough, especially for applications that were developed before Windows Vista came around: that’s when CSIDL were introduced. But still: Windows XP already had %APPDATA% (the environment variable equivalent to CSIDL_APPDATA, it pointed to %USERPROFILE%\\Application Data)

Applications should store data under either of below locations. Values are KNOWNFOLDERID constants with CSIDL constants in parenthesis where available. Some have .NET equivalents in the System.Environment.SpecialFolder enumeration:

  • FOLDERID_LocalAppData (CSIDL_LOCAL_APPDATA)

    The file system directory that serves as a data repository for local (nonroaming) applications.

  • FOLDERID_LocalAppDataLow (n/a)

    The file system directory that serves as a data repository for local (nonroaming) applications that run under “low integrity” (like in a web browser).

  • FOLDERID_RoamingAppData (CSIDL_APPDATA)

     The file system directory that serves as a common repository for application-specific data.

Do not use FOLDERID_Documents (CSIDL_MYDOCUMENTS) as this is specific to user documents, not application data.

The virtual folder that represents the My Documents desktop item. This value is equivalent to CSIDL_PERSONAL.

Basically use FOLDERID_LocalAppData for data that is machine specific and FOLDERID_RoamingAppData for data that should travel to other machines when the user logs on to them.

Be very careful how much you store as potentially roamed data as these can go over slow networks (both low bandwidth and low latency).

Documentation

  • Deprecated: [Wayback] CSIDL (Shlobj.h) – Win32 apps | Microsoft Docs

    CSIDL (constant special item ID list) values provide a unique system-independent way to identify special folders used frequently by applications, but which may not have the same name or location on any given system.

  • Current: [Wayback] KNOWNFOLDERID (Knownfolders.h) – Win32 apps | Microsoft Docs

    The KNOWNFOLDERID constants represent GUIDs that identify standard folders registered with the system as Known Folders. These folders are installed with Windows Vista and later operating systems, and a computer will have only folders appropriate to it installed. For descriptions of these folders, see CSIDL.

  • Reason for change: [Wayback] Known Folders – Win32 apps | Microsoft Docs

    Windows Vista introduces new storage scenarios and a new user profile namespace. To address these new factors, the older system of referring to standard folders by a CSIDL value has been replaced. As of Windows Vista, those folders are referenced by a new set of GUID values called Known Folder IDs.

    The Known Folder system provides these advantages:

    • Independent software vendors (ISVs) can extend the set of Known Folder IDs with their own. They can define folders, give them IDs, and register them with the system. CSIDL values could not be extended.
    • All Known Folders on a system can be enumerated. No API provided this functionality for CSIDL values. See IKnownFolderManager::GetFolderIds for more information.
    • A known folder added by an ISV can add custom properties that allow it to explain its purpose and intended use.
    • Many known folders can be redirected to new locations, including network locations. Under the CSIDL system, only the My Documents folder could be redirected.
    • Known folders can have custom handlers for use during creation or deletion.

    The CSIDL system and APIs that make use of CSIDL values are still supported for compatibility. However, it is not recommended to use them in any new development.

TomTom HOME Complaint

The complaint: [Wayback] Thread by @jpluimers: Who at @TomTom thought it was a smart idea to store everything TomTom HOME related on Windows under %USERPROFILE%\Documents

Who at @TomTom thought it was a smart idea to store everything TomTom HOME related on Windows under %USERPROFILE%\Documents filling up document storage (especially hard when you have a cloud backup!) with some 100 gigabytes.

It should have been at level %LOCALAPPDATA% at best.
A friend asked me to help figure out why his cloud storage ran out of space.

TOMTOM used 99% of his document storage space. These are not even documents at all: just map data either downloaded or from the device.

%LOCALAPPDATA% or even better %USERPROFILE%\AppData\LocalLow
You should get your Windows developers acquainted to CSIDL and KNOWNFOLDERID.

CSIDL is deprecated but usually has better descriptions of the values than KNOWNFOLDERID: docs.microsoft.com/en-gb/windows/win32/shell/csidl

Use FOLDERID_LocalAppDataLow or FOLDERID_LocalAppData, not FOLDERID_AppDataDocuments

KNOWNFOLDERID documentation is at docs.microsoft.com/en-us/windows/win32/shell/knownfolderid and points to the corresponding CSIDL values, if any.

In addition, newer versions of TomTom HOME should migrate old data to the correct locations.
I know that’s hard, but software development is.

The above is the unwrap of four tweets.

Related

–jeroen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: