This started as https://bugzilla.novell.com/show_bug.cgi?id=430657

- Start gedit and hit File/Open.

- In the file chooser, go to a folder that has *not* been opened in Nautilus before.

- Drag a file from the file chooser and drop it on the desktop.

The file is copied, but the icon appears in the first available slot, rather than in the position you dropped it.

Now, visit the source folder in Nautilus.  Drag another file from the file chooser to the desktop.  You'll see that the new icon appears in the location where you performed the drop, as expected.

This happens because of the following.  First, copy_move_file() does essentially this:

  copy_the_file();
  nautilus_file_changes_queue_schedule_metadata_copy();
  nautilus_file_changes_queue_schedule_position_set();

The metadata changes are queued, and they are processed later.  When nautilus_file_changes_consume_changes() runs, it does this:

  nautilus_directory_schedule_metadata_copy();
  nautilus_directory_schedule_position_set();

In metadata_copy(), this happens:

  1. Metadata for the source directory is not read yet, so an async read is started.  Metadata for the desktop (the destination in the example above) is already loaded.

Then metadata_copy() returns, but it leaves an async read going on.  Then, position_set() does this:

  2. Metadata for the destination is already loaded, so it writes the new file's position there.

Later, the async read finishes:

  3. real_copy_file_metadata() gets called.  First of all, it calls real_remove_file_metadata() on the destination, and then does the copy.

This causes the already-written position to be erased!  Later, when the desktop gets asked for the new icon's position, it returns "no position" as there is no metadata set for that anymore.

When you visit the source folder in Nautilus, its metadata gets loaded.  That is why the second copy works as expected.