> > Now in svn. Preservation of times on symlinks (as opposed to their > > targets) seems to be impossible. > > Yes... that's what I see, even with "/bin/cp -a symlink ." I've always > assumed the "copied" symlink is simply created anew with as many attributes > as possible preserved when the "-a" switch is used. Simply, there's no function to do it. Any attempt to use the normal mechanism passes through to the link's target. So presumably, apps don't even try to do it. > I thought at first, that this was a problem with the revised code, but > the behavior I am about to describe occurs with the official 0.3 release > as well. > > When I move a file from one dir to another and back again, I often get: > > File operation in progress, file.move added to queue > > I don't know any way to flush the queue, The included file ACTIONS is generally worth a look. Action "pending.delete" will do it. But by default, that's not bound to anything. BUT moving an item such as you describe below should be finished well before the clicked button has popped back up, so no need to queue it. so I am obliged to wait for the > operation to complete. However, it never does. Upon quitting, e2 then > segfaults. Perversely, I'd like to solve that before your other issue. I very rarely get a task that lasts long enough to allow me to debug closing before the task is complete. I compiled with debug, and get: > > > [DEBUG ] e2_action_run (from:, rt:file.move) 8< ........... > [DEBUG ] e2_action_run (from:, rt:pending.delete) I don't get the behaviour that you're reporting. The order of messages that I get in such a testcase is a bit different, raising the possibility of a race in which things unexpectedly pause until other things are finished. But since it works ok sometimes, it's going to be tough to track down. This is another instance where you'll need to build some tailored files with extra debug messages. That ok? > I may or may not be able to successfully move the file back and forth > once, but never twice. Usually I get failure on the first attempt to > move the file back to the original location. Regards Tom -- Users can unsubscribe from the list by sending email to emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by logging into the web interface.