File Manager Move of Xtra Long Full Name Leaves Ghost

[therube]

File Manager Move of eXtra Long Full Name Leaves Ghost
(Yet another ugly Subject: line...)


In general, similar to: Certain Characters in a Filename are not Monitored on Change


The deal...

So I have some Long Full Name (path+filename) file, so > ~260 chars or so.

I want to perform some operation on it...
But various programs cannot handle it - fully, for various reasons.

So often what I need to do for other programs to be able to work on the files, is to shorten the Full Name in some manner.
Sometimes rename the filename suffices. Sometimes move the file to some shorter path location.

What I have been seeing of late, & using my file manager, Servant Salamander [which also deals poorly with Long Full Names] is that after some rename/move of the file, I'll end up with a ghost ["dead" entry] showing in Everything.
That entry shows the name itself, but no size or date (again like the linked thread).


Now, how am I going about it ... in a chaotic manner, but typically along these lines:


Attempt an operation, say a compare.
Highlight a couple files in Everything, SentTo -> Compare.
Compare fails, I realize the reason, Long Full Name.

I copy Full Name using Everything (F6 shortcut in my case), & paste that into Salamander, in order to change to that directory/file.
But that often fails, because of its own Long Full Name issues.

So I copy Path Name using Everything (F5 shortcut in my case) & paste that into Salamander.
That almost never fails, simply because the total path ends up being short enough.

At that point, I try to move the file from within Salamander to its parent directory, but that fails - Long Full Name issues still.
Next attempt is to rename the file (from within Salamander), to some short file name, which I can do.
And I rename it (generally) to "xxx.ext" (literally xxx).
So now I have some often relatively long path & some short file name, so path/xxx.ext.

Ctrl-X to cut the file, back out (up) the directory tree any number of times & paste the file back in.
So I'm now situated at some much shorter path.
Ctrl+V to paste the file (xxx.ext) into said shorter path directory.
Then I rename the file back to its original name, so, some much shorter path\some typically longish file name file.ext.

And at that point, I'm typically where I can then perform my wanted actioned on the file.
So back to Everything, highlight the file name, SendTo -> Compare.
Compare works on this now shorter Full Name successfully.

Done.


Everything typically shows a ghost entry, from original location, name only, no size or date.
And also the renamed/moved (real) file, in its new location, will full specs.
This ghost entry is "dead". It is not there, & no actions can be taken on it.
The renamed/moved (real) file, is as expected.

Now all of this, I pretty much expect, I'm used to it, so no big deal.


But, just now, similar situation, but this time, I was not left with a ghost entry.
I only ended up with the real file, real location, but in this one instance, it shows no size or date.
Other then that, the file is "live" & I can open it or edit it or ...


If not for this last oddity, I wouldn't even have mentioned it.
Again, not really concerned, only noting that it happened.

[void]

Everything typically shows a ghost entry, from original location, name only, no size or date.

I've been trying to reproduce this issue without much luck.
Tried on Windows XP and Windows 7, what OS are you using?

Strange the size and date are not shown, this might be a clue to the issue.
Did the long file name show the correct size and date before the shortening of the filename/parent folder name?

Is this long file name included as a NTFS or folder index?

[therube]

> OS:

Win7 x64

> size and date are not shown:

For the the "ghost" entry, except in this one instance.

> Did the long file name show the correct size and date before the shortening of the
> filename/parent folder name?

Yes.

> Is this long file name included as a NTFS or folder index?

Normal NTFS index.

[therube]

It's going to happen - shortly, so ...

File name, including extension, 255 chars
Path length, including trailing \, 22 chars

So that puts the full file name at ~277 chars

I can open the directory (obviously) in Windows Explorer
I can open the directory in Salamander

I cannot "run" the file (.mp4 movie) in either
WE: "The file name or extension is too long."
Salamander: simply ineffectual, as if I did not click on anything

I cannot rename the file in WE, simply ineffectual, as if I did not hit F2 (to rename)

Rename the file in Salamander...
F2 -> abc.mp4
That works, file is now named abc.mp4, & I can now run it (double-click) in both WE & Salamander
Opens, movie plays

At this point, Everything shows both the new name, abc.mp4, & the old name
In this case, all fields; path, size, extension, date modified, display & agree
One is there, the other a ghost

Cut (Ctrl+X) abc.mp4
Move it to a shorter path, C:\
Rename it back to its original 255 char filename

Can run the file from both WE & Everything

Everything displays the same filename twice
Once in its original location
Once in its new location, C:\

The "one" in the original location is a Ghost

Pretty sure the only way to get rid of it is to do a Force Rebuild of the Index

(Don't think a Ctrl+Q & Restart will do it? And not in a position, at the moment, to test.)

Win7, x64
Everything 1.4.0.713b (x86)


(Not a big deal, & I'm certainly not complaining, just stating as it is.)

[horst.epp]

And there are other file managers like Total Commander which can handle long file names much better.

[therube]

721b.

What happens now, is that the Ghost still persists, but at least the moved file is now seen.
(I think that's slightly different behavior?)

Though... the moved files is NOT seen by 'dupe: sizedupe:' ?


I originally did a 'dupe: sizedupe:'.
That pointed me to a particular set of files, two files.

One file was in a path length >260.

Then I renamed & moved the file to a shorter path, then renamed it back to its original name (now in a shorter path).

'dupe: sizedupe:' only sees the two original files.

A search on the name itself (without 'dupe: sizedupe:') now see's 3; the two original (one of which is now a ghost) files, & the newly renamed/moved file.
Odd.

[void]

I assume this a NTFS volume.

I am unable to reproduce the issue, could you please send me the verbose debug output capturing the rename.

[therube]

Yes, NTFS.

Original path+name, 267 chars:

Code: Select all

C:\Local\SANDBOX\CLEAN\drive\I\ZZZ\http.ftp.mozilla.org\pub\mozilla.org\seamonkey\067\0569067779\13912b37c462dc467db4722e44029ee0\http.ftp.mozilla.org\pub\mozilla.org\seamonkey\067\0569067779\13912b37c462dc467db4722e44029ee0\SeaMonkey cant click thick as a brick.jpg

Renamed to xxx.jpg.

Cut (Ctrl+X) xxx.jpg, back up a number of directories (parents) in the tree, moving (pasting, Ctrl+INS) xxx.jpg to a shorter path, 82 chars:

Code: Select all

C:\Local\SANDBOX\CLEAN\drive\I\ZZZ\http.ftp.mozilla.org\pub\mozilla.org\seamonkey\

Then renamed back to its original name, so path+name, 124 chars:

Code: Select all

C:\Local\SANDBOX\CLEAN\drive\I\ZZZ\http.ftp.mozilla.org\pub\mozilla.org\seamonkey\SeaMonkey cant click thick as a brick.jpg

Result:
The second file shown is left as a ghost entry.

windows 7 print screen


Non-verbose:

Code: Select all

...

(I'll look at verbose in a bit...)


The rename, cut, back up in directory tree, then paste, were done with Altap Salamander.
Originally used Everything (;-)) to find the file.
Copied path using Everything.
(Copy Full Name won't work, cause the path+name is too long to paste into Salamander.)
Paste path into Salamander, Shift+INS.
Rename filename, in Salamander, F2, from 'SeaMonkey cant click thick as a brick.jpg' to 'xxx.jpg' (just some arbitrarily shorter name, that hopefully will then end up having a path+len <260 so that I can do something further with the file).
Cut (Ctrl+X) xxx.jpg (in Salamander).
Back up X-number of directories in Salamander (to end up at some shorter path).
Paste that cut file into the new location (still named as xxx.jpg).
Rename (F2 in Salamander) 'xxx.jpg' back to its original name 'SeaMonkey cant click thick as a brick.jpg'.

Review what Everything shows.
Two entries, one in the <260 path+name location, the other, the ghost, in its original location.

[therube]

Guessing... SFN (& I think that has happened before?):
880896924, reason RENAME_OLD_NAME (00001000), filename SEAMON~1.JPG

Code: Select all

880896924, reason RENAME_OLD_NAME (00001000), filename SEAMON~1.JPG

[therube]

& I think that has happened before?

Yes, Certain Characters in a Filename are not Monitored on Change.

(I think we've come full circle .)

[void]

880896924, reason RENAME_OLD_NAME (00001000), filename SEAMON~1.JPG

Thanks for the verbose output.

Guessing... SFN (& I think that has happened before?):

Sounds familiar, looks like Salamander is renaming with the short file name?
I'm not certain why the short file name would be used in the USN Change Journal..
Everything doesn't understand the short file name in the USN change journal, that's why you are seeing the ghost.

I'll look into a solution, looks like I'll have to grab the correct LFN from the mft..

[void]

I've tried renaming with the SFN and still get the LFN in the USN change journal here.
I'm gonna put this down as a bug with the USN Change Journal. The USN Change Journal is probably using the first name attribute record for the name. Very odd that it doesn't use the actual name record that was changed.

Everything would need to track FRNs to determine what file SEAMON~1.JPG referenced, currently Everything does not index this information.
FRN tracking would require an additional 8 bytes of memory for each file, something I'm trying to avoid.

[therube]

Just a little rehash...


Everything & deadwood


Salamander is old
(that is not to say it is not good,
just that it is old, [heh. it was good in 2016, & before, & it is still good, in 2022.]
so it doesn't really handle some things, such as LFN, well,
or at all, at times)


that said...


it's (inline) Rename (F2)
/can/ see a 255-char name
& */can/ rename it


*/can/
- it cannot rename 255 to 254
but it can rename to */something shorter/
(which i guess is going to be based upon 'Full Path'
- see that i'm getting a little more "techinically" correct)


*/something shorter/
in this case, it looks like a (any) Full Path < 260 will work
(so [again] a combination of path+name)

Code: Select all

	Everything
	Version 1.5.0.1317a (x86)
	Windows NT 6.1
	Processors 4
	IsAdmin 0
	AppData 0
	Service 1
	cmdline .\everything.exe  -instance 15
	SetActiveWindow failed 00000000
	WM_ACTIVATE 00000000 00000000, lastfocus 02f011b0, current focus 02f011b0
	PIPE READ 8
	PIPE READ 4
	PIPE READ 3 12
	update m 36 0faacbd8
	PIPE READ 8
	update index T:
	PIPE WRITE 34 52
	PIPE READ 8
	PIPE READ 1104
	PIPE READ 0 1112
	USN RENAME_OLD_NAME HOME34~1.WMV
	PIPE READ 8
	USN RENAME_NEW_NAME home3412...        (this is the newly renamed, now shorted name)
	USN CLOSE RENAME_NEW_NAME home3412...  (this is the newly renamed, now shorted name)
	PIPE WRITE 34 52
	PIPE READ 8
	PIPE READ 8
	PIPE READ 0 16
	read usn journal T: in 0.003473 seconds
	PIPE WRITE 35 20
	PIPE READ 8
	PIPE READ 51
	PIPE READ 0 59
	PIPE WRITE 35 20
	PIPE READ 8
	PIPE READ 491
	PIPE READ 0 499
	PIPE READ 8
	updated T: in 0.001642 seconds
	resume ntfs monitor 36

point here is,
when this is done /in Salamander/ (& possibly with other "older" programs),
it is done via a SFN
> USN RENAME_OLD_NAME HOME34~1.WMV
(assuming i am picking up on this correctly ?)


& it is this that Everything is not "seeing" (accounting for)
leading to "deadwood" entries in Everything


not particularly concerned about this,
more just pointing out what is going on...


(& no, other file managers are not for me...)

[void]

> USN RENAME_OLD_NAME HOME34~1.WMV
(assuming i am picking up on this correctly ?)

Yes, this is a limitation with the USN Journal and Everything.

When renaming with the shortname, the shortname is stored in the USN Journal.
Everything will not be able to lookup this file with the shortname.
Everything does not keep the file ID either, so the old long file will be left in the index as deadwood.

Forcing a rebuild will remove the deadwood files from Tools -> Options -> Indexes -> Force Rebuild.

[horst.epp]

...
(& no, other file managers are not for me...)

Just for interest
What is so good that you want to stay with Salamander.
In a previous job I had to compare the whole market of 3rd party file managers.
Salamander had nothing better then many other free file managers at this time.
Today almost any free file manager beats it in all aspects.

[therube]

Well, #1, it was done right, from day 1 (way, way, way back when it was freeware).
If you know Norton Commander (DOS), this was Norton Commander for Windows (where the Norton Commander windows version was not).

Muscle memory is important.
(Yes, I know in some other products you can change shortcut keys...)
(I've used it - at least since 1998.)

In almost all respects, it still does everything (like Everything) very well.
It almost all respects it does everything (like Everything), intuitively.

It has a clean UI & UX.
It's robust.

It has the features I need.
It's extensible, to a point. Can use (at least some) TotalCommander extensions.

It works.

Lacks... LFN. "Unicode". Tabs. Oh, that's about it (or at least that I can think of, offhand).


I do have an instance of FreeCommander open, for one particular task.
Otherwise, over time, various times, I looked, dabbled - briefly with; Unreal Commander, Double Commander, Total Commander, Cubit Explorer, EF Commander, Explorer++, File Commander, File Navigator, Just Manger, Multi Commander, NexusFile, Nomad, wxCommander (& I'm sure, more).