none
Office 365 saves to a different %LOCALAPPDATA% location than the %LOCALAPPDATA% location shown in Windows Explorer RRS feed

  • Question

  • When opening an Office file via Egnyte WebEdit, some of our users have reported that WebEdit does not upload changes to Egnyte despite the file being successfully saved in Office. In these cases, we’ve found that Office 365 did not write changes to file on local filesystem during save. This behavior prevented our application Egnyte WebEdit from detecting and uploading changes to Egnyte cloud. The only way to resolve this is to reinstall Office 365.

    When Egnyte WebEdit downloads a Office file from the cloud, it is saved to a temporary location under the following folder:

    %LOCALAPPDATA%\EgnyteWebEdit\temp
    The file then is then opened in Office 365.

    In these cases, we found that Office 365’s view of the %localappdata% path (where WebEdit saves files to) is different from what is visible to WebEdit and Windows Explorer. See the example below, where the view on the left (Office 365's view) differs to the view on the right (Explorer and WebEdit's view):

    https://egnyte.egnyte.com/dl/i0JTl5fR9c

    What might have caused this to happen?

    • Moved by Baron Bi Thursday, November 8, 2018 6:55 AM
    Thursday, November 1, 2018 6:45 PM

All replies

  • Hi,

    thanks for posting here.

    >>Office 365 saves to a different %LOCALAPPDATA% location than the %LOCALAPPDATA% location shown in Windows Explorer

    This forum is about desktop application development. For your case which isn't related to development issues, I suggest you post on this forum below.

    https://answers.microsoft.com/en-us

    Your understanding and cooperation will be grateful.

    Best Regards,

    Baron Bi


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, November 2, 2018 1:35 AM