Re: Move does not preserve timestamps.

  • From: <tpgww@xxxxxxxxxxx>
  • To: emelfm2@xxxxxxxxxxxxx
  • Date: Thu, 2 Nov 2006 18:36:23 -0500

> > 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.

Other related posts: