timing oddity between Rename & Cut

[therube]

timing oddity between Rename & Cut


with ongoing disk i/o (~200 MB/s between different drives, ~100 each on the +R end & the +W end)
i can
Rename, Cut, then go to Paste elsewhere
only to receive a message:

Code: Select all

	Could not find this item
	This is no longer located in S:/K/xfr/...
	Verify the item's location and try again.

(& yes, that dialog definitely has the original name, NOT the renamed name
So Everything displays the renamed name [actually not certain of that?], but the Cut picks up the original name)

(& then, a moment thereafter, on a re-Cut, the Paste pastes successfully)

Rename, Cut & (attempted) Paste is on the drive being Written to (S:)
(though the file in question has already been written to the drive,
i.e., not part of the ongoing Writes to the drive)

this happens at the Cut phase
it must be cutting the original name
so when you go to Paste, you're hit with the error message

so it is a Rename-Cut, in rapid sequence, where the Cut cuts the original name, not the renamed name
- when the actual Paste attempt happens is irrelevant


(while the Error Message dialog is open)
Undo History shows,
Rename, with the correctly renamed name
then,
Move with the original name
New Name, at that point in time is empty
New Path, is the correct (expected) Path location

Index Journal shows,
File Rename (correctly, & only)

(after the Error Dialog [Item Not Found] is dismissed, Cancel [as Try Again is ineffective, as expected])
Undo History & Index Journal remain unchanged
including with the purported Move having happened [still showing in Undo History] (though it did not, happen)

an attempted Undo (Ctrl+Z) correctly says
[Move] Unable to move. Error 2: The file was not found or the filename is invalid to too long.
(& at that point, the [Undo History] Move item is removed [not re-Moved ]


when this happens, clipboard also shows the orig filename rather then the renamed name
(i wonder if i might not, at times, actually be Cutting the old name before Everything as actually re-written out the new name
- with me thinking i've Cut the new name [as i may not actually see the complete name, overflow or whatnot], & even if i did
see, i may or may not catch the discrepancy)
that must be (part of it too), i'm actually Cutting the old name, as the new name hadn't actually re-written the old name - yet

when this happens, you'll also note that while you Cut a file (& you did),
the files' icon will not display as "cut" (gray out), because you've actually cut the file (name) that was before the rename

(man. i wonder what would have happened with even slower media, or greater system load, like in the floppy days .)

[NotNull]

man. i wonder what would have happened with even slower media, or greater system load, like in the floppy days .

You mean ... today?
San Francisco will spend $212 million to bid 5.25-inch floppy disks goodbye

[void]

The file rename is not immediate in Everything.

NTFS volumes are only updated from the USN Journal.
There's a small delay of about 1 second before Everything picks up the new filename.

I will look into reducing this delay after a rename from within Everything.

[void]

A small update:

Everything will see the rename almost immediately.

The display may not update for 1 second.
Cutting the file will cut the up-to-date filename. (the old filename might still be displayed)

Is the rename on a spinning disk?
-It is strange the rename is not detected before you cut the file.

I have on my TODO list to process the delete/move/rename operation immediately.
However, I have concerns with Everything getting out of sync with the USN journal.

[void]

Everything 1.5.0.1384a will immediately update any NTFS volumes after a rename from Everything.

There's still a small delay.
However, it should help minimize the issue.