Files used by Opera

Last update: June 1, 2011

This document identifies files used by Opera 10.0x and later release versions for Mac, UNIX, and Windows operating systems. It can be useful for those who like to manually adjust their copy of Opera.

Please note Opera Unite and Opera Widgets will be disabled by default in Opera 12.00 and unavailable as of Opera 12.50. More information about this is available here.

Voice support will be removed as of Opera 12.00, as the voice-detection library is no longer supported by the third-party vendor.

BitTorrent will not be available in the MacOS version of Opera as of Opera 12.00.

On this page...

File name changes

Some Opera file names have changed starting with the release of Opera 10.0x.

Cross-platform file name changes

Old file name	New file name
speeddial_defaults.ini	standard_speeddial.ini
accounts_defaults.ini	standard_accounts.ini

Mac file name changes

Old file name	New file name
Opera 9 Preferences	operaprefs.ini
Opera Direct History	typed_history.xml
Opera Global History	global_history.dat
Bookmarks	bookmarks.adr
Site Preferences	override.ini

UNIX file name changes

Old file name	New file name
opera6.ini	operaprefs.ini
opera6rc	operaprefs_default.ini
opera6rc.fixed	operaprefs_fixed.ini
opera6.adr	bookmarks.adr
english.lng	en.lng (it is also in the locale/en folder ONLY)

Windows file name changes

The general path to these files is:

Old file name	New file name
opera6.ini	operaprefs.ini
OperaDef6.ini	operaprefs_default.ini
Opera6.ini	operaprefs_fixed.ini
opera6.adr	bookmarks.adr
english.lng	en.lng (it is also in the locale/en folder ONLY)
images (folder in app data, etc.)	icons

Customizing with the Preferences Editor

Opera recommends using the opera:config Preferences Editor to customize your copy of Opera.

1. Start Opera.
2. Type opera:config in the Opera address bar.
3. Press Enter.

This will open the Opera Preferences Editor with the following items that you can adjust. Note: Each item is hyperlinked to its place in the Opera Preferences Editor.

Manually editing files

Warning: Manual editing of these files can make your copy of Opera unusable, or cause data loss. Do not tweak while Opera is running, except when told otherwise. Deleting files will cause data loss! Always make backups before making any changes.

Mac-specific items: The Opera.app package is securely signed. Any modifications to the contents within the package will break the seal, and may result in security warnings from the system firewall every time Opera starts up. You may change the package name and set attributes for it in Finder.

Platform package resources and preferences

Reference is made to two locations for resources:

• Package: Package resources are in the read-only installed part of Opera.
• Preferences: Preferences are in the read/write access user copied/created files.

Mac application package

Folder	Description
/Application/Opera.app	This is the default install location.

Mac application package breakdown

Folder	Description
Opera.app/Contents/Resources	This is the location for default resources.
Opera.app/Contents/Resources/defaults	These are the default .ini and .xml files.
Opera.app/Contents/Resources/images	These are several images currently used as video controls.
Opera.app/Contents/Resources/skin	These are skin files.
Opera.app/Contents/Resources/styles	These are style files, with user styles in a subfolder.
Opera.app/Contents/Resources/lang_code.proj	These are localized resources using the system language code.
Opera.app/Contents/Resources/unite	These are the default and available Opera Unite applications.
Opera.app/Contents/Resources/widgets	These are default widgets to be installed, if included.

Mac preferences

• On Mac computers we have three locations that hold the user writable data.
• They can all be considered as the preferences area.
• Note: In the following table, "~/" represents the Home folder.

Folder	Description
~/Library/Application Support/Opera	Any user data of significant size should be placed here.
~/Library/Caches/Opera	Any temp/cache data should be placed here.
~/Library/Opera	All other preferences should be placed here.
THE NEXT TWO SEEM OUTDATED	THE NEXT TWO SEEM OUTDATED
~/Library/Preferences/com.operasoftware.Opera.plist	These are the system window and dialog settings.
~/Library/Preferences/com.operasoftware.OperaWidgets.plist	This is the reference list of installed widgets.

Mac system

Folder	Description
/Applications/Opera.app/Contents/PlugIns/	These are plug-ins that are bundled with Opera.
/Library/Internet Plug-Ins	These are plug-ins that are controlled by the system.
~/Library/Internet Plug-Ins	These are plug-ins that are controlled by the user.
/Library/Preferences/Opera Preferences [1]	These are system-wide preferences for all Opera installations.
/Library/Preferences/Opera Preferences/Fixed [1]	These are system-fixed, overridden preferences for all Opera preferences.

[1] These are never set up with the installation. The files must be manually placed here by a system administrator.

UNIX package

UNIX users please note:

• ${PREFIX} = /usr (rpm/deb), /usr/local (tar: system install) or ~/.local (tar: user install)

Folder	Description
${PREFIX}/bin/opera	This is the wrapper script to launch Opera.
${PREFIX}/bin/opera-widget-manager	This is the wrapper script to launch the Opera Widget Manager.
${PREFIX}/bin/uninstall-opera	This is the wrapper script to uninstall Opera (for tar packages only).
${PREFIX}/lib/opera	These are the binaries.
${PREFIX}/lib/opera/plugins	This is the plug-ins install location.

UNIX package breakdown

UNIX users please note:

• ${PREFIX} = /usr (rpm/deb), /usr/local (tar: system install) or ~/.local (tar: user install)

Folder	Description
${PREFIX}/share/opera/locale	These are localized files all in subdirectories following the system language codes.
${PREFIX}/share/opera/skin	These are the skin files.
${PREFIX}/share/opera/styles	These are style files, with user styles in a user subdirectory.
${PREFIX}/share/doc/opera	These are licenses.
${PREFIX}/share/icons/hicolor	These are icons.
${PREFIX}/share/man/man1	These are man pages.
${PREFIX}/share/pixmaps	These are pixmaps (for deb package only).

UNIX preferences

Folder	Description
~/.opera	Any user data is placed here.

UNIX system

Folder	Description
/etc	These are system-wide resources (operaprefs_default.ini and operaprefs_fixed.ini)

Windows package

• Opera can be installed and run from everywhere.
• The default Windows installation location is:

  %PROGRAMFILES%\Opera (this requires administrator rights)
  

When Opera is installed with the single user option

• User settings are saved into Opera\profile.
• E-mails are saved into Opera\profile\mail.

When Opera is installed without the single user option

• User settings are separated between the roaming profile and the local profile.
• The actual location of the directories for the current user is defined in the Windows registry at:

  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
  

Windows package breakdown

Path	Description
Opera\	This is the installation location.
Opera\*.exe;Opera\*.dll	This is the actual executable file.
Opera\operadef6.ini	These are the default Opera settings.
Opera\english.lng	This is the fallback human language.
Opera\search.ini	These are the default searches.
Opera\license.rtf	This the license for a language selected during installation.
Opera\defaults\	These are all other .ini files, default bookmarks, and other settings.
Opera\locale\	These are all of the languages.
Opera\locale\*\*.lng	These are language files for other languages.
Opera\locale\*\license.txt	These are the localized licenses.
Opera\program\plugins\	These are plug-ins installed by Opera, or by other programs aware of Opera.
Opera\Skin	These are the default installed skins.
Opera\Styles	These are the default installed cascading style sheets.
Opera\Widgets	These are the default installed widgets.

Windows preferences

Profile type	Registry value	Description
Roaming	AppData	Only a small amount of data can be put here; the roaming profile is limited to a maximum of 30 MB.
Local	Local AppData	The rest of the user data can be placed here.

Windows system

• Plug-ins from external applications can be located anywhere.
• Some of them are advertised in the Windows registry.

Platform specifics

Mac

Path	Description
Opera.app/Contents/PlugIns	These are plug-ins used within Opera (Java and PDE). Do not confuse this with Flash, etc.

UNIX

UNIX users please note:

• ${PREFIX} = /usr (rpm/deb), /usr/local (tar: system install) or ~/.local (tar: user install)

Folder	Description
${PREFIX}/lib/opera/plugins	This is the plug-ins install location.
${PREFIX}/share/opera/uninst	This is an uninstallation file.
${PREFIX}/share/doc/opera	These are licenses in English only, and a copy from locale/en.
${PREFIX}/share/icons/hicolor	These are icons.
${PREFIX}/share/man/man1	These are man pages.
${PREFIX}/share/pixmaps	These are pixmaps.

Windows

Path	Description
Opera\program\plugins\	These are plug-ins installed by Opera, or by other programs aware of Opera.

Layout folders

The following sections describe each system's layout folders.

UNIX users please note:

• ${PREFIX} = /usr (rpm/deb), /usr/local (tar: system install) or ~/.local (tar: user install)

Binaries

System	Folder	Description
Mac	<installation path>/Opera.app/Contents/MacOS <installation path>/Opera.app/Contents/Frameworks	Mac binaries
UNIX	${PREFIX}/lib/opera/	UNIX binaries
Windows	<installation path>\Opera\	Windows binaries

Resources

UNIX users please note:

• ${PREFIX} = /usr (rpm/deb), /usr/local (tar: system install) or ~/.local (tar: user install)

System	Folder	Description
Mac	Opera.app/Contents/Resources	Root of Opera resources on Mac
UNIX	${PREFIX}/share/opera/	Root of Opera resources on UNIX
Windows	Opera\	Root of Opera resources on Windows

Package breakdown

The <package> folder is listed (as above) for the different platforms.

Folder	Description
<package>/aux	These are auxiliary files that are needed, but should be moved.
<package>/defaults	These are default settings and fallback files.
<package>/java	These are Java files.
<package>/scripts	These are script files.
<package>/skin	These are skin files.
<package>/styles	These are style files, with user styles in a subfolder.
<package>/ui	These are user interface files, such as keyboard, dialog, and toolbar.
<package>/unite	These are the Opera Unite services files.
<package>/locale/lang_code	These are localized resources using the system language code (UNIX/Windows platforms only)
<package>/lang_code.proj	These are localized resources using the system language code (Mac platform only)
<package>/widgets	These are default widgets to install if they are included.
<package>/custom	Any custom resources are here, situated one directory lower.

Opera file formats

This section describes the binary file formats used in cache and cookie management.

The new generic format that these files are based on is structured as a sequence of tagged records with a given length. Each record may contain a number of different data types such as strings and integers, as well as arbitrary binary data, such as new records in this format.

The generic format is NOT backwards compatible with Opera 3.x and earlier, but is intended to be reasonably backwards compatible for version 4.0 and later. This means that if new fields are added by a future version, older versions will still be able to read the information that they understand, while ignoring the fields they do not understand.

There are some limits, but they are mostly concerned with the number of significant bits in the integers that are used to indicate record lengths. The formats are presently used to store the disk cache index file (dcache4.url), the visited links file (vlink4.dat), the download rescue file (download.dat) and the cookie file (cookies4.dat). The formats are described in the following sequence:

• The generic binary format used in the new formats.
• The special constants and data organizations used in the cache, visited links and download file formats.
• The special constants and data organizations used in the cookie format.

The formats for the windows history, news files and global history files are the same as the ones used by Opera v3.x and are outside the scope of this document.

Generic binary format

Data types

Integers used in the format are unsigned, and stored in big-endian/network style (Most Significant Byte first). Integers stored inside the records are also stored in the big-endian format, but may be signed, and may be truncated.

The following datatypes are used in this document:

Datatype	Description
int*	This is a signed integer of * bits.
uint*	This is an unsigned integer of * bits.
byte	This is a 8 bit unsigned value.
string	This is a sequence of characters (not null terminated).
time_t	This is uint32 representing a time value in seconds since 00:00 Jan 1, 1970 GMT. The representation may be increased past 32 bit in the future.
tag_id_type	This is an unsigned integer whose size is selected by the idtag_length header field. The application must convert from this type to its internal unsigned integer representation, preferably uint32. For more information, see the file header format.
payload_length_type	This is an unsigned integer whose size is selected by the length_length header field. The application must convert from this type to its internal unsigned integer representation, preferably uint32. For more information, see the file header format.
record	This is a separately defined sequence of fields.

Data records

The general record format has the following form:

struct record
{
// application specific tag to identify content type
tag_id_type tag_id;
// length of payload
payload_length_type length;
// Payload/content of the record
bytepayload[length];
};

NOTE: The number of bytes in tag and length may change, see below.

The fields of each record have the following meanings:

tag_id

The identifier of the record. This value is application specific, and can be used to indicate the meaning of the payload content.

The actual content type of the record depends on the definitions used for the actual file or super-record.

Tag_id values in which the MSB (Most Significant Bit) is set to 1, are reserved for records with implicit no length. The tag_id field is NOT followed by a length field, nor a payload buffer. Such records are used as Boolean flags: True if present, False if not present.

In the binary storage of a file this means that the MSB of the internal storage integer must be stored as the MSB of the first byte in the tag field. This places a limit on how many tags can be used for a given tag_id integer length. When a file is read into a program, the program must take care to move the MSB of the binary stored tag to a common (internal) bit position, such as the MSB of the program's own unsigned integers.

bytes	This is the max id available (excluding MSB).
1	0x7f
2	0x7fff
3	0x7fffff
4	0x7fffffff

While it is technically possible to use the same tag id (without the MSB) for a normal record and a flag record (such as 0x0001 [16 bit tag] for the payload record and 0x8001 for the flag record), this is not encouraged.

length

This field is the number of bytes in the payload that immediately follow the field. It may be zero.

payload

The payload is a sequence of bytes of the length indicated by the length field.

The meaning of the contents is indicated by the definition for the given record or file structure. Examples of organization may be an array of records, unsigned integers, signed integers, or characters.

It is recommended that only records of the types described here are used if the type of the data varies, as variable (un-tagged) type formats tend to be inflexible and difficult to maintain across versions, especially when compatibility with older versions is desired.

Single item integers (signed or unsigned) may be truncated (zero bytes removed), but arrays of integers must always use a fixed number of bytes to represent values and derive the number of items from the payload length. If the number of bytes needed to represent the values changes in a future version a new tag should be used.

File Format

These elements are not stored as records, but directly in binary:

uint32 file_version_number;
uint32 app_version_number;
// number of bytes in the id tag, presently 1
uint16 idtag_length;
// number of bytes in the length part of a record, presently 2
uint16 length_length;
// array of records, number determined by length of file
struct record items[];

The present version number of the file format (file_version_number) is 0x00001000, where the lower 12 bits (bitmask 0x00000fff) represent the minor version number, the rest is the major version number. Changes in the minor version must not be used if the file format is changed in such a manner that older versions of the software cannot read the file successfully. If the major version number is newer (or older) than the application can read, it must not read the file.

The integer sizes are absolute for a given major version, and the integer size for the file version number is fixed in any version.

The "app_version_number" is the version number of the application and is independent of the file_version_number. It may be used by the application to determine necessary actions needed to provide forward or backward compatibility that is outside the scope of the file formats. The interpretation of the application version number is application dependent.

The "idtag_length" and "length_length" fields gives the number of bytes used in the records for the idtags, as defined by the tag_id_type, and the payload length fields, as defined by payload_length_type, respectively.

Specifically, the values of these fields define tag_id_type and payload_length_type as the following integer types:

Value	tag_id_type	payload_length_type
in	idtag_length	length_length
1	uint8	uint8
2	uint16	uint16
3	uint24	uint24
4	uint32	uint32

The application's internal representation of these types is not defined, but uint32 is recommended. How an application should handle "idtag_length" or "length_length" values larger than 4, or values larger than its internal unsigned integer size, is not defined, but the application should implement the rules specified in the forward compatibility guide for such situations.

Present versions of Opera 4.x uses idtag_length=1 (uint8) and length_length=2 (uint16).

After the header, only records follow. The organization of the records and their interpretation is application specific.

Forward Compatibility

An older version of an application using this file format that is NOT able to use long integers should, regardless of this, try to process the file, but should bypass the record if the tag of the record's numerical value exceeds the version's own integer range, i.e. the integer overflows. However, if the the length of the record exceeds the application's limits on integers or buffer capabilities, it must not continue to process the file.

All applications must ignore tag values that they do not understand.

Cache file formats

This section details the record tags and formats used for the visited link file (vlink4.dat), the disk cache index file (dcache4.url) and the download rescue file (download.dat). The present app_version_number of these files is 0x00020000 (major version 2, minor 0).

These files use records (of different tag values) which contain a sequence of records with tags from the same set of tag ids. The different files use these tags for their records:

File	Tag id	Version number
Disk cache	0x01	0x00020000
Visited Links	0x02	0x00020000
Download	0x41	0x00020000

Each file consists of records of ONLY this type, with the exception of the Disk cache index file, which also contains a single record with the id 0x40, which contains a 5 character string used to find the next free cache file number (oprXXXXX).

Each record is again a sequence of records with the same binary representation format as the records in the file.

Common elements between all files

These elements are used by all of the cache related files. In the case of visited links, these are the only fields presently used.

NOTE: "(0x0001 | MSB_VALUE)" means that the most significant bit in the local unsigned integer is to be set. If 32 bit values are used, that means the tag's value is 0x80000001.

Tag ID	Contents	Meaning
0x0003	string	This is the name of the URL, fully qualified.
0x0004	time_t	This is last visited.
0x000b	MSB_VALUE: flag	The URL is a result of a form query.
0x0022	record	Contains the name and last visited time of relative link in the document; it may repeat.

Content tags of relative link (tag 0x0022) records

Tag ID	Contents	Meaning
0x0023	string	This is the name of the relative link.
0x0024	time_t	Last visited.

Fields used by disk cache and download rescue files

Tag ID	Contents	Meaning
0x0005	time_t	This is localtime, when the file was last loaded; it is not GMT.
0x0007	uint8	Status of load: 2 - Loaded 4 - Loading aborted 5 - Loading failed
0x0008	uint32	This is content size.
0x0009	string	This is the MIME type of content.
0x000a	string	This is the character set of content.
0x000c	MSB_VALUE: flag	File is downloaded and stored locally on a user's disk; it is not part of the disk cache directory.
0x000d	string	This is the name of the file (cache files: only local to cache directory).
0x000f	MSB_VALUE: flag	Always check if modified.
0x0010	record	This contains the HTTP protocol specific information.
0x0050	uint16 ("len")	Embedded URLs: This signifies that the URL is stored in the cache index. It is a uint16 ("len") followed by an array of "len" bytes that represent the content of the URL.
0x0052	uint32	Identifies the network type from which a given resource has been loaded. 0: localhost 1: private 2: public 3: undetermined
0x0053	MSB_VALUE: flag	Used to detect if the MIME type was initially empty.
0x002B	string	This is FTP Modified Date Time.
0x002B	MSB_VALUE: flag	Never flush this URL.
0x0037	uint32	These are associated files.

Fields used only by the download rescuefile

Tag ID	Contents	Meaning
0x0028	time_t	Identifies the time when the loading of the last/previous segment of the downloaded file started.
0x0029	time_t	Identifies the time when the loading of the last/previous segment of the downloaded file was stopped.
0x002A	uint32	The is the amount of bytes in the previous segment of the file being downloaded. If the time the loading ended is not known, this value will be assumed to be zero (0) and the download speed set to zero (unknown).
0x002C	uint32	Enables the ability to resume the downloaded URL. 0: Not resumable 1: May not be resumable (or field not present) 2: Probably resumable

Fields used in the HTTP protocol specific record

All methods are by default GET; at present it is not possible to cache POST requests.

Tag ID	Contents	Meaning
0x0015	string	HTTP date header
0x0016	time_t	Expiry date
0x0017	string	Last modified date
0x0018	string	MIME type of document
0x0019	string	Entity tag
0x001A	string	Moved to URL (Location header)
0x001B	string	Response line text
0x001C	uint32	Response code
0x001D	string	Refresh URL
0x001E	uint32	Refresh delta time
0x001F	string	Suggested file name
0x0020	string	Content Encodings
0x0021	string	Content Location
0x0025	uint32	Together with tag 0x0026 (both must be present), this identifies the User Agent string last used to load the resource. This value identifies the User Agent string. This value is used internally, and should not be modified.
0x0026	uint32	Together with tag 0x0025 (both must be present), this identifies the User Agent string last used to load the resource. This value identifies the User Agent sub version. This value is used internally, and should not be modified.
0x0030	MSB_VALUE: flag	Reserved for future use.
0x0031	MSB_VALUE: flag	Reserved for future use.
0x002F	MSB_VALUE: flag	Always validate before displaying, also when moving in history.
0x002D	string	This signifies a link relation.
0x002E	string	This signifies content language.
0x003A	uint32	This signifies a HTTP age header.
0x003B	structure	This signifies a list of HTTP headers. It is a sequence of 0x003C records (headers from an HTTP response).
0x003C	structure	This signifies a single HTTP Header. It is a sequence of a single 0x003D record and a single 0x003E record.
0x003D	string	This signifies the name of the HTTP header.
0x003E	string	This signifies the value of a HTTP header.

Cookie file format

This section describes the record tags and formats used for the storage of cookies (cookies4.dat). The present app_version_number of this file type is 0x00002000 (major version 2, minor 0).

The cookie file is organized as a tree of domain name components, each component then holds a tree of path components and each path component may contain a number of cookies.

NOTE: The components are a sequence of records, terminated with a flag record, not a single record.

Domain components

The domain components are used to organize the cookies for each server and domain for which cookies or cookie filtering capabilities are defined.

A domain component is started with a domain record, which holds the domain name and some flags for that particular domain. It is then followed by a path component holding the cookies and subdirectory path components (and cookies), followed with a path component terminator and any number of subdomain components before it is terminated by a domain-end flag record.

E.g: cookies for the domain www.opera.com will be stored in this manner:

["com" record]
  ["opera" record]
["www" record
  [cookies]
  [Path components]
  [Path component terminator]
  [other domains]
[end of domain flag ("www")]
  [end of domain flag ("opera")]
[end of domain flag ("com")]

All names of domain components are non-dotted except IP addresses, which can only be stored with the complete IP address as a Quad dotted string, e.g. "10.11.12.13" are stored at the top level and cannot contain any subdomains.

A Domain Record uses the tag "0x01" and contains a sequence of these fields:

Tag ID	Contents	Meaning
0x001E	string	This is the name of the domain part.
0x001F	int8	This is how cookies are filtered for this domain; if not present, the filtering of the parent domain is used. All cookies from this domain are accepted. No cookies from this domain are accepted. All cookies from this server are accepted. Overrides 1 and 2 for higher level domains automatics. No cookies from this server are accepted. Overrides 1 and 2 for higher level domains. Domain settings apply to all subdomains, except those with a server specific selection.
0x0021	int8	This is the handling of cookies that have explicit paths which do not match the URL setting the cookies. If enabled in the privacy preferences the default is to warn the user, but when warning is enabled such cookies can be filtered by their domains: Value 1 indicates reject, and 2 is accept automatically.
0x0025	int8	While in the "Warn about third party cookies" mode, this field can be used to automatically filter such cookies. All third party cookies from this domain are accepted. No third party cookies from this domain are accepted. All third party cookies from this server are accepted. Overrides 1 and 2 for higher level domains automatics. No third party cookies from this server are accepted. Overrides 1 and 2 for higher level domains. Domain settings apply to all subdomains, except those with a server specific selection.

This record can be followed by zero or more path components defining toplevel paths on servers in the domain and always terminated by a path component terminator record. Then zero or more domain components may follow.

A domain component is terminated by a (0x0004 | MSB_VALUE) flag record.

Path components

The path components organize the cookies defined for a given directory in a given domain, as well any subdirectories of this directory that have cookies defined.

Except for the path component starting immediately after the domain component record, each path component always starts with a path record, and is then followed by any number of cookie records and subdirectory path components.

The path record uses the record id "0x0002", and the record has this field record:

Tag ID	Contents	Meaning
0x001D	string	This is the name of the path part.

The path component terminator is the (0x0005 | MSB_VALUE) flag record.

Cookie Records

The cookie entries are stored in records of type "0x0003" and have the following field records:

Tag ID	Contents	Meaning
0x0010	string	This is the name of the cookie.
0x0011	string	This is the value of the cookie.
0x0012	time_t	This is the expiry date.
0x0013	time_t	This is shows when last used.
0x0014	string	This is the Comment/Description of use (RFC 2965).
0x0015	string	This is the URL for Comment/Description of use (RFC 2965).
0x0016	string	This is the domain received with version=1 cookies (RFC 2965).
0x0017	string	This is the path received with version=1 cookies (RFC 2965).
0x0018	string	This is the port limitations received with version=1 cookies (RFC 2965).
0x0019	MSB_VALUE: flag	The cookie will only be sent to HTTPS servers.
0x001A	int8+	This is the version number of a cookie (RFC 2965).
0x001B	MSB_VALUE: flag	This cookie will only be sent to the server that sent it.
0x001C	MSB_VALUE: flag	This is reserved for delete protection: not yet implemented.
0x0020	MSB_VALUE: flag	This cookie will not be sent if the path is only a prefix of the URL. If the path is /foo, /foo/bar will match but not /foobar.
0x0022	MSB_VALUE: flag	If true, this cookie was set as the result of a password login form, or by a URL that was retrieved using a cookie that can be tracked back to such a cookie.
0x0023	MSB_VALUE: flag	If true, this cookie was set as the result of a HTTP authentication login, or by a URL that was retrieved using a cookie that can be tracked back to such a cookie.
0x0024	MSB_VALUE: flag	In "Display Third party cookies" mode this flag will be set if the cookie was set by a third party server, and only these cookies will be sent if the URL is a third party. Cookies that were received when loading a URL from the server directly will not be sent to third party URLs in this mode. The reverse is NOT true. NOTE: If a third party server redirects back to the first party server, the redirected URL is considered third party.