Red Hat Bugzilla – Bug 149641
Saving fails when target is a symlink
Last modified: 2007-11-30 17:11:00 EST
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):
Steps to Reproduce:
1.Create a document named abc.sxc - save and close oocalc
2.ln -s abc.sxc 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.
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
Created attachment 111411 [details]
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