From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Galeon/1.3.19 Description of problem: When you try and save overwriting a symlink, you get: Could not create backup copy. Typical usage is: I created a symlink on my desktop to an oocalc document, and I want to open it by simply clicking on the symlink. It works, but when I try to save it later, I get the above message. I need to Save As.. and overwrite the document itself (not the symlink). Version-Release number of selected component (if applicable): 1.1.3-6.5.0.fc3 How reproducible: Always Steps to Reproduce: 1.Create a document named abc.sxc - save and close oocalc 2.ln -s abc.sxc cde.sxc 3.open cde.sxc 4.change anything, and try to save. 5.You get the "Could not create backup copy" warning. Actual Results: The document has not been saved at all. Expected Results: I think it should follow the symlink and overwrite the document. Any user gets the impression that it opens 'cde.sxc' but fails to save it. Additional info: Well, I have hardly any idea of how to debug this. I tried a strace... I got some weird results, it seems it creates a directory with a .bak extension in the backup dir, and the tries to open the original document with O_DIRECTORY. This seems so absurd to me. I've had a look at the source but it's all obfuscated C++ (I'm no C++ guy at all) and wasn't able to isolate the open() call. Luckily, it seems the warning message can be generated only in two places in the whole source, so I hope someone more skilled than me in C++ and more comfortable with OO sources will be able to spot this pretty easily. I'm ranking this as 'normal', since I think syslinks are no rocket science. Of course I can stop using them at all, but I don't know any other way to get the same functionality (I keep links to "hot" documents on my desktop, and documents themselves under some deep directory structure). BTW, I tested this with oowrite as well, and got the same result.
Yeah, there is quite a bit of C++ foo going on (classes on classes on classes), but what you're looking for is probably in sal/osl/unx/file*.c. I think almost all the byte stream APIs come down to the stuff in those files. "sal" stands for System Abstraction Layer BTW, so most non-GUI platform dependent stuff is in that module.
Created attachment 111411 [details] partial strace This is a partial strace for normal case: strace -o /tmp/oocalc.strace oocalc abc.sxc fgrep .sxc /tmp/oocalc.strace I just changed the sheet and saved it. Please note, no mkdir.
Created attachment 111412 [details] partial trace (symlink) strace -o /tmp/oocacl.strace2 oocalc cde.sxc fgrep .sxc /tmp/oocacl.strace2 cde.sxc is a symlink to abc.sxc. Please note the weird mkdirs. Again I just changed the sheet and hit save. Now got the warning "Could not create backup copy". I haven't included full strace output because it's quite big of course.
I wasn't able to make much sense out of the sal/osl/unx/file*.c at first glance. I'll try harder tomorrow. What really puzzles me is the mkdir. The O_DIRECTORY is weird, too, but I haven't seen it in the sources, I'll accept it as a glibc thing. But I'm not believing that glibc packs a mkdir() call on top of an open(). In the OOO source, mkdir() is wrapped by osl_psz_createDirectory(), and I see no reason why one would call it to open a file, even in presence of symlinks. This nested classes stuff is quite confusing to me (or are those meta-meta-classes?) and I may be missing the obvious. I'd really be glad if someone else could confirm the bug...
Fixed in the 2.0 series http://qa.openoffice.org/issues/show_bug.cgi?id=21034 Available in rawhide with 1.9.84-1 upwards