Onenote2013在同步时出现：抱歉,同步时出错.将稍后再试. (错误代码: 0xE4020017)

Posted 2023-03-25

参考技术A 很抱歉，同步 OneNote 时遇到问题。
请尝试下列故障排除建议，或滚动到本页面末尾以将您的同步问题报告给 OneNote 产品团队。
重新打开笔记本以同步 OneNote
如果无法同步的笔记本存储在 OneDrive 上或较新版本的 SharePoint 上，请尝试在 OneNote Online 中打开该笔记本。这有助于确定问题是由服务器还是 OneNote 导致的。
在 OneNote 中，单击“文件”>“信息”。
右键单击受影响的笔记本名称下面显示的 URL，然后单击“复制”。
在 Web 浏览器中，在地址框中单击，然后按 Ctrl+V 粘贴所复制的 URL。
按 Enter 以在 OneNote Online 中加载笔记本。
如果您不能在浏览器中成功打开该笔记本，则问题可能是 OneNote 桌面版本导致的。关闭并重新打开笔记本通常会清除并成功重置连接。
在 OneNote 中，单击“文件”>“信息”。
在受影响的笔记本的名称旁边，单击“设置”，然后单击“关闭”。
在浏览器内 OneNote Online 中切换回笔记本，然后单击功能区上的“在 OneNote 中打开”。
如果您无法在 OneNote Online 中打开和查看笔记本，则说明同步问题的根源可能是您的服务器。如果该笔记本存储在 OneDrive 上，请检查 Microsoft 服务状态页以了解是否有任何已知中断或断电。如果该笔记本存储在 SharePoint ，则您需要联系您的管理员以报告问题并对其进行故障排除。
返回页首
查找和修复损坏的笔记本分区以同步 OneNote
有时您的共享笔记本除了其中一个分区之外，其他分区都可以正常同步。您可以通过执行下列操作来验证是否存在这种情况：
在 OneNote 中，单击“文件”>“信息”>“查看同步状态”。
在“共享笔记本同步”对话框中，单击上方有黄色三角形警告的任何笔记本图标以查看导致同步问题的任何分区的名称。
单击其中包含该分区的笔记本旁边的“立即同步”按钮。
单个笔记本分区有时可能完全停止同步。如果您有一个分区与最新笔记本的其余分区不同步，可尝试执行以下解决方法：
在同一笔记本中创建一个新分区。
将旧分区中的所有页面复制（但不要移动）到您刚刚创建的新分区中。方法可以是右键单击每个页面，然后单击“移动或复制”。
所有页面均已从旧分区复制到新分区之后，请按 Shift+F9 手动同步笔记本。如果出现进度条，请等待其完成。
如果执行这些步骤可以成功同步所创建新分区中的页面，则可以安全地删除旧分区，然后继续在新分区中操作。旧分区一经删除，您就可以将新分区重命名为所删除分区的相同名称。

读取和写入共享文件时出现 IPC 同步问题

【中文标题】读取和写入共享文件时出现 IPC 同步问题

【英文标题】：IPC synchronization issue while reading & writing into shared files

【发布时间】：2015-04-22 05:53:00

【问题描述】：

在访问一组共享文件时，从多个同时运行的进程调用以下代码。这些文件包含条目的列表。 （我之所以提到文件 (pl.) 只是因为带有 entries 的实际列表在磁盘上被分解成更小的文件。）

规定每个条目必须有一个唯一的自增ID。为此，我正在为文件访问同步实现一个命名互斥锁，但显然我仍然遗漏了一些东西，因为有时我在这些 条目 中得到重复或重复的 ID（下面的 dwUniqueID 变量） .

有人能说明原因吗？

接下来是简短的代码，为简洁起见，省略了所有错误检查。我还将它剥离为裸 API 调用：

//Global variables
HANDLE hFile = INVALID_HANDLE_VALUE;
HANDLE hMutex = NULL;

然后初始化（完成一次）：

//INFO: Error checks are omitted for brevity!

PSECURITY_DESCRIPTOR psdMutex = NULL;
::ConvertStringSecurityDescriptorToSecurityDescriptor(
    L"D:(A;;GA;;;WD)(A;;GA;;;AN)S:(ML;;;;;S-1-16-0)",
    SDDL_REVISION_1, &psdMutex, NULL);

SECURITY_ATTRIBUTES sa;
sa.nLength = sizeof(sa);
sa.bInheritHandle = FALSE;
sa.lpSecurityDescriptor = psdMutex;

//Create global IPC mutex
hMutex = ::CreateMutex(&sa, FALSE, L"Global\\My_IPC_Mutex_Name");

::LocalFree(psdMutex);

然后第一次打开所需的文件之一：

//INFO: Error checks are omitted for brevity!

//Open initial file
ReopenFile();

void ReopenFile()

    //Close previous file
    if(hFile != INVALID_HANDLE_VALUE)
    
        ::FlushFileBuffers(hFile);
        ::CloseHandle(hFile);
        hFile = INVALID_HANDLE_VALUE;   
    

    //Create/open file
    hFile = ::CreateFile(strFilePath, 
        GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_READ | FILE_SHARE_WRITE,
        NULL,
        OPEN_ALWAYS,
        FILE_ATTRIBUTE_NORMAL | FILE_FLAG_WRITE_THROUGH,
        NULL);

然后，为了测试我的 IPC 同步，我在一个长循环中调用以下代码：

//INFO: Error checks are omitted for brevity!
for(;;)

//Enter IPC critical section
if(::WaitForSingleObject(hMutex, INFINITE) ==  WAIT_OBJECT_0)

    //Read last DWORD from file
    DWORD dwUniqueID = 0, ncbWrtn;

    LARGE_INTEGER liFileSz = 0;
    ::GetFileSizeEx(hFile, &liFileSz);
    if(liFileSz.QuadPart >= sizeof(DWORD))
    
        LARGE_INTEGER li0;
        li0.QuadPart = -(LONGLONG)(sizeof(DWORD));
        ::SetFilePointerEx(hFile, li0, NULL, FILE_END);

        ::ReadFile(hFile, &dwUniqueID, sizeof(DWORD), &ncbWrtn, NULL);
    

    //Do other work
    //...

    if(CheckIfThisFileIsFull(liFileSz))
    
        //File must be closed and another one opened
        ReopenFile();
    

    //Increment unique ID
    dwUniqueID++;

    //And write it into file
    LARGE_INTEGER li1 = 0;
    ::SetFilePointerEx(hFile, li1, NULL, FILE_END);
    ::WriteFile(hFile, &dwUniqueID, sizeof(DWORD), &ncbWrtn, NULL);

    //Flush file
    ::FlushFileBuffers(hFile);

    //Leave IPC critical section
    ::ReleaseMutex(hMutex);

else break;

【问题讨论】：

使用文件锁定（LockFile 等）而不是互斥锁可能更明智。

【参考方案1】：

FlushFileBuffers 的 MSDN 文档让我相信 Windows 仍然允许缓存写操作，因此当您的互斥锁被释放时，不能保证该文件与其他进程保持一致。

【讨论】：

您可以尝试使用共享内存或共享内存映射文件将无缓冲标志FILE_FLAG_NO_BUFFERING 添加到CreateFile。至少我会这样做。

是的，我也看到了FILE_FLAG_NO_BUFFERING 标志。不幸的是，它并不容易使用。需要在磁盘上的扇区大小和 RAM 中的页面大小上对齐写入。它打开了太多失败的可能性。

不，如果你调用FlushFileBuffers 保证所有其他进程将立即看到数据。但是，如果机器断电，它可能无法保证数据是安全的。

【参考方案2】：

我想我已经找到了自己问题的答案。我得到重复 ID 的原因是因为我的实现逻辑错误：当我的 CheckIfThisFileIsFull() 方法确定当前文件已满时，它会生成一个新文件，然后 ReopenFile() 会打开并开始使用它。好吧，如果有多个进程使用此方法，这将不起作用。例如，如果一个进程仍然持有旧文件，而另一个进程已经创建了一个新文件，那么第一个进程将不知道它，从而重用旧 ID 并创建一个副本。

无论如何，我感谢您的意见...如果您从我原来帖子中的 for(;;) 循环中删除我的 ReopenFile()，我的实现将适用于多进程应用程序（即不需要额外的锁。）