I have *.odt and *.ods files on an encfs encrypted (Dropbox based) volume. When I try to open these files, I get the error message "C:\Users\<user>\AppData\Local\Temp\lu2d878.tmp\lu2d87a.tmp existiert nicht." It seems to be a permission problem for tempoprary files. Files from "C:" can be opened without these problems. The problem exists on Win 7 with Libreoffice 4.1.6 and 4.2.3. Libreoffice 4.1.0.3 works fine.
Problem still exists in version: 4.2.5.2. Also using Win 7 on a x64 machine.
Version is oldest version confirmed, not newest, updating. @Jens - do you happen to know of a how to that I can quickly set up an encfs encrypted volume in Windows? I'll test if I can get instructions on how to do so
I'm using encfs4win. http://www.howtogeek.com/121737/how-to-encrypt-cloud-storage-on-linux-and-windows-with-encfs/ http://members.ferrara.linux.it/freddy77/encfs.html
Same Problem here with version 4.3.0.4 on Win7x64, using encfs through Dokan (encfs4win). No Problems on Ubuntu.
Same problem seems to be reported here: http://portableapps.com/node/39186 and here: http://ask.libreoffice.org/en/question/27825/libreoffice-odt-files-encrypted-by-boxcryptor-are-not-opening/
Solved: Had the same problem with a file on an encrypted volume. After dismounting and remounting the encrypted volume I could open the file without problems.
I too have this problem with version 4.3.0.4 on Win7x64, using encfs through Dokan (encfs4win). Dismounting and remounting the encrypted volume does not solve the problem.
(In reply to iswmar from comment #8) > I too have this problem with version 4.3.0.4 on Win7x64, using encfs through > Dokan (encfs4win). > > Dismounting and remounting the encrypted volume does not solve the problem. Please could you test with actual version of LO - 4.3.5? https://www.libreoffice.org/download/libreoffice-fresh/ Thank you
(In reply to raal from comment #9) > (In reply to iswmar from comment #8) > > I too have this problem with version 4.3.0.4 on Win7x64, using encfs through > > Dokan (encfs4win). > > > > Dismounting and remounting the encrypted volume does not solve the problem. > > Please could you test with actual version of LO - 4.3.5? > https://www.libreoffice.org/download/libreoffice-fresh/ > Thank you I tried on win8.1_x64 with latest LO 4.3.5.2 today. Same Problem !! It seems to be a problem with filenames, path or access rights while opening/decrypting the file from the encfs-dokan-folder. The tmp-path keeps the same while the names of the tmp-folder and the tmp-file in that path varies, when you try to open the again and again.
I know this bug since it appears in libreoffice. Even with the actual version 4.4.03 on Win7-x64 the problem is not solved. For me it's very annoying to C&P the libreoffice files every time i want to edit it. Any solution to this bug will be appreciate.
So, tried to find some informations today. First i tried to find some strings where the error string exists. My translation in germany let me found two places where this error could display. First: translations\source\de\sw\source\ui\app.po starting in line 1260 #: error.src msgctxt "" "error.src\n" "RID_SW_ERRHDL\n" "ERR_CODE ( ERRCODE_CLASS_PATH , ERR_AUTOPATH_ERROR )\n" "string.text" msgid "$(ARG1) does not exist." msgstr "$(ARG1) existiert nicht." Second: translations\de\uui\source.po starting in line 369 #: ids.src msgctxt "" "ids.src\n" "RID_UUI_ERRHDL\n" "(ERRCODE_UUI_IO_NOTEXISTS & ERRCODE_RES_MASK)\n" "string.text" msgid "$(ARG1) does not exist." msgstr "$(ARG1) existiert nicht." Next one try to find a conspicuous place where one of this error are set.
Version is oldest version confirmed on, not most recent tested on. Reverting change. As for this comment: For me it's very annoying to C&P the libreoffice files every time i want to edit it. Any solution to this bug will be appreciate. Solution is always the same with a free, open source, volunteer based program: (1) submit a patch; (2) find a friend, family member, colleague, co-worker, etc... to create a patch; (3) pay someone to fix it; (4) wait patiently until a volunteer submits a patch. There are thousands of bugs, enhancement requests, etc...TDF and LibreOffice has no power to dictate how these are fixed (volunteer and/or companies/individuals who pay others) decide how things are fixed. As always, patches welcome!
Hmm, what does the class SWGlossaries do? Maybe the failure exists in the function SwGlossaries::UpdateGlosPath(...) Inside this function they try to find a path with aPathOpt.GetAutoTextPath() Is it possible that this class returns an empty path? Because the initialization of this class SvtPathOptions is done one line before and as i could look into the class pathoptions.cxx in folder unotools\source\config the function GetAutoTextPath is linked to the function GetPath( SvtPathOptions::PATH_AUTOTEXT ); And inside this function, starting at line 216 the return value for SvtPathOptions::PATH_AUTOTEXT could only be an empty string because this enumeration is not handled. Who can help me to dig in deeper into this?
Joel Madero Who ca i submit a patch if i even don't have the chance to compile or debug the whole libreoffice suite. Of course it is free and open software, but i'm not in a place where i can submit a patch. For this i had to build the whole libreoffice project to find this one little, but annoying bug. The only thing i can do is to help a dev to find a codepart where a bug maybe can be. This is a bughunting plattform!
(In reply to Daimonion from comment #15) > Joel Madero > > Who ca i submit a patch if i even don't have the chance to compile or debug > the whole libreoffice suite. Why can't you compile or debug the whole suite? > > Of course it is free and open software, but i'm not in a place where i can > submit a patch. For this i had to build the whole libreoffice project to > find this one little, but annoying bug. Um - who said it's "one little" bug? Doesn't seem obvious to me that this is a minor bug. We have over 10,000,000 lines of code, very few issues are "little" as functions and files interact with one another in incredibly complex ways. > The only thing i can do is to help a dev to find a codepart where a bug > maybe can be. This is a bughunting plattform! Sure - and that's much appreciated. I was just commenting on your question as to your previous comment about how annoying this bug is. We have lots of annoying bugs (as any complex program will...whether it be open or closed source). So simply stating that it's annoying and assistance appreciated doesn't get us far...that being said, we really do appreciate the potential code pointers.
(In reply to Joel Madero from comment #16) > Why can't you compile or debug the whole suite? Because it's my first day in libreoffice source and the kids won't sleep. ;) So i didn't had the time to setup the whole ide and dependencies and stuff like that. The dependencies where really big. Sure it is a big project and it will take some time to set it up... > Um - who said it's "one little" bug? Doesn't seem obvious to me that this is > a minor bug. We have over 10,000,000 lines of code, very few issues are > "little" as functions and files interact with one another in incredibly > complex ways. > I hoped some dev with a working ide could dive deeper into this bug. As i said i doesn't have a working ide with installed dependencies for libreoffice and so i takes some time for me to dive deeper into this bug. > Sure - and that's much appreciated. I was just commenting on your question > as to your previous comment about how annoying this bug is. We have lots of > annoying bugs (as any complex program will...whether it be open or closed > source). So simply stating that it's annoying and assistance appreciated > doesn't get us far...that being said, we really do appreciate the potential > code pointers. I can understand you. Every post with "help appreciated" blabla is annoying. ;) So, back to topic. You said "we". Do you have the possibility to have a look into these codeparts? Reproducing this bug on a windows machine should also be very easy because install dokan, encfs4win and generate a crypted folder is done in less than 5 minutes. Regards Daimonion
So has this always been broken? One thing you could do is try to find exactly what version broke it (if it ever worked). If it never worked then it should get set to 'inherited from OOo" Again, version is the OLDEST version that is affected, not the latest tested on. So if 3.6.5.2 is broken but 3.6.5.1 is good, then the version should be 3.6.5.2, even if 4.3.0 is still broken. So if you could test older versions and find out if any version ever worked, that would be fantastic. No building necessary :) http://downloadarchive.documentfoundation.org/libreoffice/old/
Give me some hours/days to find out which version is the first one which is affected...
Thanks for your assistance. What I can promise you is that the more you do to help us...the more likely (although not guaranteed) it'll be that we can find someone to volunteer to fix it :) I suggest trying the oldest version first - if it's present in the oldest version, than that's the worst case scenario because then we have no point of reference. If instead it is in fact a regression, we can start trying to look at commits to see what possibly broke it. Feel free to jump into the QA chat to say hello and give us updates: http://webchat.freenode.net/?channels=libreoffice-qa We're all pretty friendly :-b
Hey Joel i'm up on the other side. ;) Okay, i have a information for you. First affected Version was v4.0.0.0.beta1/ ;) v3.6.7.2 works as expected.
Okay we're doing what we can to track this down but unfortunately there are >10,000 commits in that range :-/ Do you mind doing another test. Can you try with a recent release of OpenOffice and let us know if the bug exists there? This will help us further try to narrow it down....thanks again for helping to diagnose. I promise I'm doing what I can to narrow down the possibilities of where things went wrong (mostly as a thank you to you for being patient and offering to assist)
(In reply to Joel Madero from comment #22) > Do you mind doing another test. Can you try with a recent release of > OpenOffice and let us know if the bug exists there? This will help us > further try to narrow it down....thanks again for helping to diagnose. I > promise I'm doing what I can to narrow down the possibilities of where > things went wrong (mostly as a thank you to you for being patient and > offering to assist) No problem... Latest Version of OO (4.1.1 - AOO411m6(Build:9775) - Rev. 1617669) works like a charm with encfs I gues there is something broken in SwGlossaries::UpdateGlosPath(...) respectively with SvtPathOptions::GetPath( SvtPathOptions::PATH_AUTOTEXT ) Maybe starting in this place could help you to find the bug.
We looked at those possibilities and none of them looked relevant. So as of now just for an update we're looking at 10k+ commits that could be responsible for the regression which is unfortunate. I'll keep you informed about any updates :-/
Thanks for your information and the ongoing bughunting. If i can do something, test something or give you further information don't hesitate to contact me. Next information i don't want to hide is, that only open document formated files will not open inside such a crypted container. doc-files works very well. docx-files produces an error but opens very well. Tested under actual version 4.4.0.3 Regards Daimonion
Installed 4.4.3.2 and it seems the issue is solved. Can anyone confirm this? i will make a detailed check this evening.
4.4.3.2 works for me. The issue is solved.
Yep, for me too. Yeha
(In reply to Jens Westemeier from comment #27) > 4.4.3.2 works for me. The issue is solved. Latest version works for bug submitter (and others), so marking RESOLVED WORKSFORME.
Migrating Whiteboard tags to Keywords: (notBibisectable) [NinjaEdit]