Want to know what EndNote has to offer? Try our  free  series that guides you through the entire process. Read more here.

Contents
1    Explanation for non-technical users
     1.1    The safest general rule
2    Deeper technical explanation
     2.1    An EndNote library is not one independent document
     2.2    Database transactions must be atomic
     2.3    File synchronisation is not database replication
     2.4    Open files and file locking create further risks
     2.5    Synchronisation order is not guaranteed
     2.6    Successful synchronisation does not prove database integrity
     2.7    The correct way to synchronise an EndNote library
3    Conclusion
4    EndNote library on a network drive

1 Explanation for non-technical users

An EndNote library may look like an ordinary file or folder, but it does not behave like a Word document or a collection of PDFs. It is an active database containing references, groups, search indexes, attachments and links between many related pieces of information. EndNote describes the library itself as a database.

A database must keep all its parts in agreement. When EndNote adds or changes a reference, it may update several files in a particular sequence. The update is only safe when EndNote controls the complete operation from beginning to end.

OneDrive, Dropbox and iCloud work differently. They monitor files and copy changes to the cloud when changes are detected. They do not understand that several EndNote files form one database transaction. One file may therefore be uploaded before another, a file may be copied while EndNote is still changing it, or two computers may upload different versions of the same file.

A useful comparison is a set of account books that must always contain matching figures. EndNote updates several books together. A file-syncing service may collect one book halfway through the update and another after the update has finished. Each individual copy may appear valid, but the complete set no longer agrees.

The result may be:

• missing or duplicated references;
• damaged groups or indexes;
• attachments that can no longer be found;
• conflict copies created by the cloud service;
• a library that EndNote cannot open;
• corruption that becomes visible only later.

For that reason, Alfasoft explicitly advises users not to store a working, uncompressed EndNote library in a cloud-synchronised folder. The warning specifically includes services such as OneDrive, iCloud and Dropbox.

  1.1 The safest general rule

Keep the active EndNote library on a local drive. Use EndNote Sync or EndNote library sharing for synchronisation and collaboration. Use network or cloud storage only for closed backup, transfer or read-only copies.

2 Deeper technical explanation

  2.1 An EndNote library is not one independent document

A normal EndNote library consists of a main .enl file and a corresponding .Data folder. Both parts must remain together and consistent. The .Data folder contains additional parts of the library structure, including attachments and supporting data. Alfasoft warns that moving only the .enl file, without the matching .Data folder, can cause the loss of attachments, term lists and reference information.

The exact internal format has changed between EndNote versions. It is therefore accurate to describe an EndNote library as a database. Some newer EndNote formats use SQLite internally, but the essential support position does not depend on the database engine: the working library is a coordinated database structure and must not be synchronised as an ordinary collection of files.

  2.2 Database transactions must be atomic

Database software uses transactions to maintain consistency. A transaction should have an all-or-nothing result: either every required change is completed, or none of the changes is treated as complete.

An EndNote operation may involve changes to:

• reference records;
• indexes used for searching and sorting;
• group membership;
• attachment metadata;
• PDF or other attachment files;
• temporary, journal or supporting files.

EndNote can coordinate the order in which such changes are written on a local file system. A general-purpose cloud synchronisation client cannot see the logical transaction. It sees only separate files that have changed.

The synchronisation client may consequently upload:

1. the modified database file;
2. an index from an earlier state;
3. an attachment after a delay;
4. a temporary or supporting file while it is still being written.

The cloud copy can then represent a mixture of different points in time rather than one valid database state.

  2.3 File synchronisation is not database replication

Database replication operates at the transaction or record level and is designed to preserve database consistency. OneDrive, Dropbox and iCloud are primarily file-synchronisation systems. They normally detect that a file has changed and then transfer the changed file or changed blocks.

A file-syncing service generally has no knowledge of:

• database transactions;
• relationships between the .enl file and files inside the .Data folder;
• the correct order in which related changes must be applied;
• whether an EndNote write operation has genuinely finished;
• whether a temporary state is safe to reproduce on another computer.

Copying database files is therefore not equivalent to synchronising the database.

  2.4 Open files and file locking create further risks

Database applications commonly lock files while using them so that another process does not make incompatible changes. A synchronisation client may be unable to copy a locked file immediately, may retry later, or may process other unlocked files first. Microsoft notes that files held open by applications may not synchronise until the application releases them.

Problems become more serious when the library is opened on two computers. Each computer has a local copy and may make legitimate changes without knowing about changes made on the other computer. When both sets of files reach the cloud, the synchronisation service cannot merge individual EndNote references safely. It can only:

• overwrite one version;
• retain the other version;
• create a conflict copy;
• combine file versions that were never meant to coexist.

None of those behaviours provides transaction-safe database merging.

  2.5 Synchronisation order is not guaranteed

An EndNote library can contain many files. Cloud services process those files independently, often in parallel. Network interruptions, sleep mode, limited bandwidth, selective synchronisation and files-on-demand features may change the order or timing of transfers.

Computer A may finish writing the library, but Computer B may begin downloading before every related file has reached the cloud. EndNote on Computer B can then open a partially updated library. Opening the incomplete copy may itself produce further writes, which are subsequently synchronised back to the cloud.

A temporary inconsistency can therefore become permanent corruption.

  2.6 Successful synchronisation does not prove database integrity

A cloud client may report that synchronisation is complete because every file has been transferred successfully. The status only confirms file transfer. It does not confirm that the files collectively form a consistent EndNote library.

Corruption may remain unnoticed until EndNote:

• rebuilds an index;
• accesses a particular reference;
• opens an attachment;
• synchronises through EndNote’s own service;
• performs a library recovery;
• encounters an internal relationship that no longer matches.

A library can therefore appear to work immediately after file synchronisation while already containing structural inconsistencies.

  2.7 The correct way to synchronise an EndNote library

A working EndNote library should be kept in a normal local folder that is not managed by OneDrive, Dropbox, iCloud or another file-syncing service.

To use the same library on several computers, use EndNote’s own synchronisation or library-sharing functionality. EndNote’s synchronisation system works through the application and can process EndNote records according to EndNote’s own data model, rather than copying an active database at file level.

Cloud storage may still be used to transfer or archive a closed, compressed copy of the library, typically an .enlx file. Clarivate states that a compressed library may be stored or transferred through a cloud-synchronised location, but it should be moved out of that location before it is extracted and opened. An uncompressed working library must not be used inside the synchronised folder.

A safe workflow is therefore:

1. Close the EndNote library.
2. Create a compressed library using EndNote.
3. Store or transfer the resulting .enlx file through the cloud service.
4. On the destination computer, copy the .enlx file to a non-synchronised local folder.
5. Open and extract the library there.

A compressed copy is suitable for transfer or backup. It is not a substitute for EndNote’s own live synchronisation service.

3 Conclusion

OneDrive, Dropbox and iCloud synchronise files, not live database transactions. An EndNote library consists of interdependent database components that must be updated together and in the correct order. File-level synchronisation can interrupt that relationship, especially when files are open, several devices are involved, or transfers occur at different times.

The fact that a cloud service can copy an EndNote library does not mean that it can synchronise the library safely. Clarivate’s documented recommendation is unambiguous: keep the working library outside cloud-synchronised folders and use EndNote’s own synchronisation system for access across devices.

4 EndNote library on a network drive

The same warning applies to network drives, shared server folders and NAS storage when an EndNote library is opened with read-and-write access.

Clarivate states that keeping a read-write EndNote library on a network drive is strongly discouraged because it can lead to library corruption. The recommended arrangement is to keep the master library on a local computer and, where necessary, place only a read-only copy on the network drive.

The technical mechanism differs slightly from cloud synchronisation:

• OneDrive, Dropbox and iCloud can create inconsistent copies by synchronising related files at different times.
• A network drive introduces risks through interrupted connections, network latency, file-locking behaviour, caching and simultaneous access.
• In both cases, EndNote may lose reliable control over the coordinated writes to the .enl file and its associated .Data folder.

Even when only one person uses the library, a brief network interruption during a database write can leave the library incomplete. With multiple users, the risk increases because EndNote is not designed to be a multi-user database server. A shared folder does not provide transaction management or safe record-level merging.

A practical distinction is:

EndNote’s built-in library-sharing feature is the appropriate option for collaboration. Clarivate specifically recommends it instead of placing a working library on a shared drive.