Description of problem: If any of the files classes.conf, printers.conf, cupsd.conf are symlinks then they get broken when scheduler rewrites them. Version-Release number of selected component (if applicable): cups-1.1.23-15.1 How reproducible: always Steps to Reproduce: 1.ln -s something printers.conf 2.run/configure cupsd 3. Actual results: symlink destroyed Expected results: symlinks preserved Additional info: I have a patch but it needs a library copy() routine which strangely enough libc does not provide. Yet there is a libc rename(). Weird. There are several rename()'s in scheduler/{classes,client,printers}.c which should be changed to copy(). And somebody should write a POSIX-committee-sanctioned filecopy() or fcopy() or copy() for libc.
Why are you making them symlinks? What's the use-case for this? Seems an unusual thing to do, and not something that I would expect to be accepted upstream.
(In reply to comment #1) > Why are you making them symlinks? What's the use-case for this? Seems an > unusual thing to do, and not something that I would expect to be accepted upstream. Would you like to know what I use my computer for, and how long I use it every day first? What does anybody use symlinks for? They shouldn't use them - or at least they should justify their use of them to RedHat officals first ;-) Look mate, over here in Australia we use our computers as sophisticated and clever machines ... well, not quite as sophisticated as programmers, but I think you get my drift. Say, for example, you have 1000 machines for which you create predefined configurations which you put on a single DVD. You have a choice - either run scripts at boot time which dynamically configure each host, or instead use symlinks. In our case we have this hierarchy (somewhat simplified for your benefit): /M/etc/cups/cupsd.conf:host1 /M/etc/cups/cupsd.conf:host2 /CHG.host1/etc/cups/cupsd.conf => /M/etc/cups/cupsd.conf:host1 /CHG.host2/etc/cups/cupsd.conf => /M/etc/cups/cupsd.conf:host2 /etc/cups/cupsd.conf => /CHG/etc/cups/cupsd.conf /CHG => /CHG.host1 (or whatever) So you see - the file /etc/cups/cupsd.conf is a fixed symlink. Now by simply changing the top level symlink (eg /CHG => /CHG.host2) you can instantly change the entire configuration of the host to whatever is appropriate .. and it takes less than 1mS. In fact on the kernel command-line you can pass a HOST=host2 and have rc.sysconfig set the configuration. It works brilliantly. I can configure 1000 hosts in a few hours, and it is dead simple to maintain. (Given a couple of scripts to maintain/create the symlink hierarchies). Hope you aren't sorry that you asked.
Created attachment 125653 [details] Here is an lrename() function that should be used instead of rename() This is a lrename() function which differs from rename() in that it attempt to follow a destination symbolic link. It is as atomic as rename(). Using this function instead of rename(P) will ensure that symbolic links are preserved if possible, on the grounds that people create symbolic links intentionally and they really want all file reading/writing to go to the symlink target and not the symlink itself. Symbolic links should be transparent as far as possible.
This patch will never get accepted upstream. The policy is that for this sort of application you need to use a separate directory root instead of symbolic links.
(In reply to comment #4) > This patch will never get accepted upstream. Preemptive negativity? > The policy is that for this sort > of application you need to use a separate directory root instead of symbolic links. That might be your policy but you are wrong to try to impose it on others. Besides, it wouldn't work!
See upstream bug report I filed about this only recently: http://cups.org/str.php?L2136