LFN: Parent Paste pastes SFN & leaves dead wood
LFN: Parent Paste pastes SFN & leaves dead wood
1298:
LFN: Parent Paste pastes SFN & leaves dead wood
(that's the short story... [it gets longer]...)
AH, on a LFN, Parent -> Paste (or dir/dir -> Paste, as it was)
it pastes a *SFN*, but the (pre-existing) LFN does not get purged (from Everything)
i.e., it ends up as "dead wood"
(/that's/ what was going on [in the longer, longer edition that i may or may not get around to posting]
& it's that, the non-existent file name, that Everything still showed, that brought, pointed out the
issues with FcHash...)
LFN: Parent Paste pastes SFN & leaves dead wood
(that's the short story... [it gets longer]...)
AH, on a LFN, Parent -> Paste (or dir/dir -> Paste, as it was)
it pastes a *SFN*, but the (pre-existing) LFN does not get purged (from Everything)
i.e., it ends up as "dead wood"
(/that's/ what was going on [in the longer, longer edition that i may or may not get around to posting]
& it's that, the non-existent file name, that Everything still showed, that brought, pointed out the
issues with FcHash...)
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Thank you for the bug report therube,
I can confirm the issue.
Everything uses the shell to handle the paste.
The shell will use the short filename in the destination filename.
I have put on my TODO list to intercept the paste and handle it myself with the LFN (instead of the short filename)
This one is complicated and I don't have an easy fix yet.
I would consider this issue the limitation of Everything being unable to detect deleted hard links.
(A short filename is just a hard link)
There's no way to know the long filename related to the short filename.
Everything just see the short filename hard link being moved.
One possible fix is to handle the paste myself and use the LFN.
I can confirm the issue.
Everything uses the shell to handle the paste.
The shell will use the short filename in the destination filename.
I have put on my TODO list to intercept the paste and handle it myself with the LFN (instead of the short filename)
The USN Journal entry is using the short filename.leaves dead wood
This one is complicated and I don't have an easy fix yet.
I would consider this issue the limitation of Everything being unable to detect deleted hard links.
(A short filename is just a hard link)
There's no way to know the long filename related to the short filename.
Everything just see the short filename hard link being moved.
One possible fix is to handle the paste myself and use the LFN.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
The following is probably of the level "baby with a chainsaw", but I post it anyway.
Out of curiousity, I did some "research" on the USN Journal (long time ago) and found that the specification has changed through the years.
For example, there is version 2 and currently we are at version 4.
I noticed that in V4 there isn't even a filename specification anymore:
So that would mean that a file delete could not be detected by Everything as only the FRN is specified and that would point to a filename that no longer exists.
... and that is where I realized that this is all way above my paygrade, as Everything is clearly able to detect deleted files (without storing the FRN in the database).
I did have a point to make here, but totally forget what it was.(will add it if it comes back)
Time for more coffee ...
Out of curiousity, I did some "research" on the USN Journal (long time ago) and found that the specification has changed through the years.
For example, there is version 2 and currently we are at version 4.
I noticed that in V4 there isn't even a filename specification anymore:
Code: Select all
typedef struct {
USN_RECORD_COMMON_HEADER Header;
FILE_ID_128 FileReferenceNumber;
FILE_ID_128 ParentFileReferenceNumber;
USN Usn;
DWORD Reason;
DWORD SourceInfo;
DWORD RemainingExtents;
WORD NumberOfExtents;
WORD ExtentSize;
USN_RECORD_EXTENT Extents[1];
} USN_RECORD_V4, *PUSN_RECORD_V4;
... and that is where I realized that this is all way above my paygrade, as Everything is clearly able to detect deleted files (without storing the FRN in the database).
I did have a point to make here, but totally forget what it was.(will add it if it comes back)
Time for more coffee ...
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Everything 1.5.0.1299a will now handle the pasting of a single item with a very long filename by itself.
The Windows shell will attempt to use the short path where possible.
However, it will not use a short basename to prevent this exact issue.
I prefer to allow the use of the short basename as it makes accessing these files possible in other circumstances.
I have added a shell_short_basename ini setting if you would like the same limitation as the Windows Shell.
To disable the use of short basenames:
The Windows shell will attempt to use the short path where possible.
However, it will not use a short basename to prevent this exact issue.
I prefer to allow the use of the short basename as it makes accessing these files possible in other circumstances.
I have added a shell_short_basename ini setting if you would like the same limitation as the Windows Shell.
To disable the use of short basenames:
- In Everything, type in the following search and press ENTER:
/shell_short_basename=0 - If successful, shell_short_basename=0 is shown in the status bar for a few seconds.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Everything 1.5.0.1300a will now only handle LFN pasting by itself when the short filename and long basename exceeds 259 characters.
Everything 1300a will now also handle multiple cut/copied files/folders.
Everything 1300a will now also handle multiple cut/copied files/folders.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
I can't believe it. How did I not take 1300 home (& it says it just above)! [Maybe I wasn't here at the time.]
(So in that regard, disregard below...)
(So in that regard, disregard below...)
1299
Still issues here.
> USN DATA_EXTEND CREATE SIFD24~1.MP4
Parent -> Paste
with LFN, still results in SFN (at least sometimes)
Code: Select all
Everything Version 1.5.0.1299a (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 00940fd6, current focus 00940fd6 WM_ACTIVATE 00000001 00000000, lastfocus 00940fd6, current focus 00000000 FOCUS 0 FOCUS restore add nav add nav COMMAND 40021 add nav ParseDisplayName 80070057 Y:\XOUT\BACKUP9D\........ - ................. 14-1+2+4 ....'.'................. (...... ..... .....) ......'......'.......'......' (.. ... ....... ....) ......,.......&.... (..... & ..... ........ ....) - ........., .............,............,....... (.... 709, 1.58.19)...4 got pidls 0.003359 COMMAND 41023 COMMAND 41019 TTN_SHOW 296 603 - 2 1, 1438 x 20 TTN_POP ENTER ACTION add nav got pidls 0.001139 _ui_shell_IDataObjectAsyncCapability_create ParseDisplayName W:\Y\XOUT\BACKUP9D\........ - ................. 14 - .... '.' . ... . ....... ..... (...... ..... ..... ......) ......'......'.......'......'... ....... - .......,.........,.......,............,..........,.............,...... ......-.... ...... 14 (.4 ....)...4 pidl focus from path 13fd6d40 pidl focus 13fd6d40 1 pidls get menu pidls: 1 cdfmc2 00000000 00000000 00000000 00000000 00000000 got menu 14283b38 menu type 1 menu type 3 QueryContextMenu... QueryContextMenu 0000006a track menu 02f91249 default 32798 menu count 34 menu item info fail 87 wid 8: 101 (00000064) 00000000 VERB open wid 8: 102 (00000065) 00000000 VERB MediaInfo wid 9: 103 (00000066) 00000000 VERB HashMyFiles wid 10: 105 (00000068) 00000000 VERB sandbox wid 11: 106 (00000069) 00000000 VERB VirusTotal wid 13: 98 (00000061) 80070057 wid 15: 96 (0000005f) 80070057 wid 16: 97 (00000060) 80070057 wid 18: 95 (0000005e) 00000000 VERB PickLinkSource menu item info fail 87 wid 21: 28 (0000001b) 00000000 VERB PreviousVersions wid 22: 32765 (00007ffc) 80070057 menu item info fail 87 wid 24: 32764 (00007ffb) 80070057 wid 25: 25 (00000018) 00000000 VERB cut wid 26: 26 (00000019) 00000000 VERB copy menu item info fail 87 wid 28: 17 (00000010) 00000000 VERB link wid 29: 18 (00000011) 00000000 VERB delete wid 30: 19 (00000012) 00000000 VERB rename wid 31: 32766 (00007ffd) 80070057 wid 32: 20 (00000013) 00000000 VERB properties rem dbl sep idCommand 32773 COMMAND 42424 shellexecute invoke W:\Y\XOUT\BACKUP9D READ 8 READ 4 PIPE READ 3 12 update m 1 0cb0e828 READ 8 LEAVE ACTION update index W: USN CREATE SIFD24~1.MP4 WM_ACTIVATE 00000000 00000000, lastfocus 00940fd6, current focus 00940fd6 USN DATA_EXTEND CREATE SIFD24~1.MP4 USN DATA_EXTEND DATA_OVERWRITE CREATE SIFD24~1.MP4 USN BASIC_INFO_CHANGE DATA_EXTEND DATA_OVERWRITE CREATE SIFD24~1.MP4 USN BASIC_INFO_CHANGE CLOSE DATA_EXTEND DATA_OVERWRITE CREATE SIFD24~1.MP4 read usn journal W: in 0.008461 seconds updated W: in 0.000043 seconds update index E: PIPE WRITE 34 52 READ 8 READ 344 DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces s_fd_update_events_thread_proc... processed 4 usn records in 0.000479 seconds PIPE READ 0 352 DB_WAIT: _db_journal_notification_event_proc waited 0.005030 seconds USN DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf READ 8 new results 9847 USN DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf ui->listview_was_focus_in_view 1 USN CLOSE DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf new results 1836137 PIPE WRITE 34 52 ui->listview_was_focus_in_view 1 READ 8 READ 8 new results 57430 PIPE READ 0 16 ui->listview_was_focus_in_view 0 READ 8 read usn journal E: in 0.024368 seconds PIPE WRITE 35 20 READ 8 READ 95 PIPE READ 0 103 READ 8 PIPE WRITE 35 20 READ 8 READ 65 PIPE READ 0 73 READ 8 updated E: in 0.008734 seconds resume ntfs monitor 1 PIPE WRITE 33 52 processed 2 usn records in 0.000611 seconds READ 8 PIPE READ 0 8 DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waiting for _db _monitor_ntfs_process_fd_update_events_thread_proc... READ 8 DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waited 0.003803 seconds READ 8 READ 4 PIPE READ 3 12 update m 1 0cb0e828 READ 8 update index E: PIPE WRITE 34 52 READ 8 READ 344 PIPE READ 0 352 USN DATA_TRUNCATION SVCHOST.EXE-326C71F5.pf READ 8 USN DATA_EXTEND DATA_TRUNCATION SVCHOST.EXE-326C71F5.pf USN CLOSE DATA_EXTEND DATA_TRUNCATION SVCHOST.EXE-326C71F5.pf PIPE WRITE 34 52 READ 8 READ 8 PIPE READ 0 16 READ 8 read usn journal E: in 0.009801 seconds PIPE WRITE 35 20 READ 8 READ 95 PIPE READ 0 103 READ 8 PIPE WRITE 35 20 READ 8 READ 65 PIPE READ 0 73 READ 8 updated E: in 0.007020 seconds resume ntfs monitor 1 PIPE WRITE 33 52 processed 2 usn records in 0.000089 seconds READ 8 PIPE READ 0 8 DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waiting for _db _monitor_ntfs_process_fd_update_events_thread_proc... READ 8 DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waited 0.002949 seconds WM_ACTIVATE 00000001 00000000, lastfocus 00940fd6, current focus 00000000 FOCUS 0 FOCUS restore
Re: LFN: Parent Paste pastes SFN & leaves dead wood
1299 (& don't know if 1300 would do the same?)
Parent -> Paste
source is Y:
name length: 244
total source: 258
wanted to paste do W:
result would have been total: 260
-with that, /Windows/ reports:
'Destination Path Too Long'
-The file name(s) would be too long for the destination folder... [tot: 260]
(which isn't correct - on Windows part, cause the file name is perfectly valid...)
Y:\XOUT\FRUIT
123456789-123456789-123456789-123465789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-.mpg
W:\Y\XOUT\FRUIT
Maybe we also need a check where basename+filename of "output dir" > 259.
Parent -> Paste
source is Y:
name length: 244
total source: 258
wanted to paste do W:
result would have been total: 260
-with that, /Windows/ reports:
'Destination Path Too Long'
-The file name(s) would be too long for the destination folder... [tot: 260]
(which isn't correct - on Windows part, cause the file name is perfectly valid...)
Y:\XOUT\FRUIT
123456789-123456789-123456789-123465789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-.mpg
W:\Y\XOUT\FRUIT
Maybe we also need a check where basename+filename of "output dir" > 259.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Nope, 1300 still gives me SFN.
> USN CREATE OPUD-0~2.MP4
Also note, as it is, currently...
LFN, Parent->Paste
- with an Everything "generated" SFN,
- it is possible that the SFN will generate an overwrite CONFLICT
(that potentially references an entirely different file;
i.e., there may happen to be an existing destination SFN,
that happens to match the LFN->SFN - from the SOURCE)
- so if you blindly performed the overwrite... (you're overwriting an unexpected file)
> USN CREATE OPUD-0~2.MP4
Code: Select all
Everything
Version 1.5.0.1300a (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 012703d0, current focus 012703d0
WM_ACTIVATE 00000001 00000000, lastfocus 012703d0, current focus 00000000
FOCUS 0
FOCUS restore
add nav OPU
add nav OPU
COMMAND 40021
add nav OPU
ParseDisplayName 80070057 .:......54.39.....-005 .... ........ ... .... ..... ..
. ..... ..... ......... ... ... ......., ... ..... .... ..... ..... .... .... ..
... ..... .... .. ...., ..... ...... ... ....... ..... ..... ....... ... .......
, ..... .... ...... ..... ........ .... ..............4
got pidls 0.003471
WM_ACTIVATE 00000000 00000000, lastfocus 012703d0, current focus 012703d0
WM_ACTIVATE 00000001 00000000, lastfocus 012703d0, current focus 00000000
FOCUS 0
FOCUS restore
add nav OPU
add nav OPU
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 1 0cbfe828
PIPE READ 8
update index E:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 344
PIPE READ 0 352
USN DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE READ 8
USN DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
USN CLOSE DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
read usn journal E: in 0.023220 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 95
PIPE READ 0 103
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 65
PIPE READ 0 73
PIPE READ 8
updated E: in 0.007984 seconds
resume ntfs monitor 1
PIPE WRITE 33 52
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
processed 1 usn records in 0.000265 seconds
PIPE READ 8
PIPE READ 0 8
DB_WAIT: _db_journal_notification_event_proc waited 0.006508 seconds
PIPE READ 8
processed 1 usn records in 0.000041 seconds
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waiting for _db
_monitor_ntfs_process_fd_update_events_thread_proc...
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waited 0.001905
seconds
COMMAND 41019
ENTER ACTION
add nav OPU
ParseDisplayName 80070057 .:........54.39.....-005 .... ........ ... .... .....
... ..... ..... ......... ... ... ......., ... ..... .... ..... ..... .... ....
..... ..... .... .. ...., ..... ...... ... ....... ..... ..... ....... ... .....
.., ..... .... ...... ..... ........ .... ..............4
got pidls 0.011624
_ui_shell_IDataObjectAsyncCapability_create
ParseDisplayName W:\Y\XOUT\54.39\....-005 .... ........ ... .... ..... ... .....
..... ......... ... ... ......., ... ..... .... ..... ..... .... .... ..... ...
.. .... .. ...., ..... ...... ... ....... ..... ..... ....... ... ......., .....
.... ...... ..... ........ .... ..............4
ParseDisplayName 80070057 W:\Y\XOUT\54.39\....-005 .... ........ ... .... .....
... ..... ..... ......... ... ... ......., ... ..... .... ..... ..... .... ....
..... ..... .... .. ...., ..... ...... ... ....... ..... ..... ....... ... .....
.., ..... .... ...... ..... ........ .... ..............4
pidl focus from path 00000000
pidl focus 13937858
1 pidls
get menu pidls: 1
cdfmc2 00000000 00000000 00000000 00000000 00000000
got menu 04573fd8
menu type 1
menu type 3
QueryContextMenu...
QueryContextMenu 0000006a
track menu 036b034b
default 32798
menu count 34
menu item info fail 87
00000000
wid 8: 101 (00000064)
VERB open
00000000
wid 8: 102 (00000065)
VERB MediaInfo
00000000
wid 9: 103 (00000066)
VERB HashMyFiles
00000000
wid 10: 105 (00000068)
VERB sandbox
00000000
wid 11: 106 (00000069)
VERB VirusTotal
80070057
80070057
80070057
00000000
wid 18: 95 (0000005e)
VERB PickLinkSource
menu item info fail 87
00000000
wid 21: 28 (0000001b)
VERB PreviousVersions
80070057
menu item info fail 87
80070057
00000000
wid 25: 25 (00000018)
VERB cut
00000000
wid 26: 26 (00000019)
VERB copy
menu item info fail 87
00000000
wid 28: 17 (00000010)
VERB link
00000000
wid 29: 18 (00000011)
VERB delete
00000000
wid 30: 19 (00000012)
VERB rename
80070057
00000000
wid 32: 20 (00000013)
VERB properties
rem dbl sep
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
idCommand 32773
COMMAND 42424
shellexecute invoke W:\Y\XOUT\54.39
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 1 0cbfe828
PIPE READ 8
WM_ACTIVATE 00000000 00000000, lastfocus 012703d0, current focus 012703d0
WM_ACTIVATE 00000001 00000000, lastfocus 012703d0, current focus 00000000
FOCUS 0
FOCUS restore
add nav OPU
add nav OPU
LEAVE ACTION
update index W:
USN CREATE OPUD-0~2.MP4
USN DATA_EXTEND CREATE OPUD-0~2.MP4
USN DATA_EXTEND DATA_OVERWRITE CREATE OPUD-0~2.MP4
USN BASIC_INFO_CHANGE DATA_EXTEND DATA_OVERWRITE CREATE OPUD-0~2.MP4
USN BASIC_INFO_CHANGE CLOSE DATA_EXTEND DATA_OVERWRITE CREATE OPUD-0~2.MP4
read usn journal W: in 0.007532 seconds
updated W: in 0.000059 seconds
update index E:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 344
PIPE READ 0 352
USN DATA_TRUNCATION SVCHOST.EXE-326C71F5.pf
PIPE READ 8
USN DATA_EXTEND DATA_TRUNCATION SVCHOST.EXE-326C71F5.pf
processed 4 usn records in 0.000219 seconds
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
DB_WAIT: _db_journal_notification_event_proc waited 0.004355 seconds
USN CLOSE DATA_EXTEND DATA_TRUNCATION SVCHOST.EXE-326C71F5.pf
PIPE WRITE 34 52
new results 57136
PIPE READ 8
PIPE READ 8
ui->listview_was_focus_in_view 1
PIPE READ 0 16
new results 480
PIPE READ 8
read usn journal E: in 0.023552 seconds
PIPE WRITE 35 20
ui->listview_was_focus_in_view 1
PIPE READ 8
PIPE READ 95
PIPE READ 0 103
PIPE READ 8
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 65
PIPE READ 0 73
PIPE READ 8
updated E: in 0.011368 seconds
resume ntfs monitor 1
PIPE WRITE 33 52
PIPE READ 8
PIPE READ 0 8
PIPE READ 8
processed 2 usn records in 0.000144 seconds
DB_WAIT: db_itemref_get waiting for _db_monitor_ntfs_process_fd_update_events_th
read_proc...
DB_WAIT: db_itemref_get waited 0.002919 seconds
WM_ACTIVATE 00000000 00000000, lastfocus 012703d0, current focus 00000000
WM_ACTIVATE 00000001 00000000, lastfocus 012703d0, current focus 00000000
FOCUS 0
FOCUS restore
add nav OPU
add nav OPU
WM_ACTIVATE 00000000 00000000, lastfocus 012703d0, current focus 012703d0
Also note, as it is, currently...
LFN, Parent->Paste
- with an Everything "generated" SFN,
- it is possible that the SFN will generate an overwrite CONFLICT
(that potentially references an entirely different file;
i.e., there may happen to be an existing destination SFN,
that happens to match the LFN->SFN - from the SOURCE)
- so if you blindly performed the overwrite... (you're overwriting an unexpected file)
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Everything 1.5.0.1301a improves pasting long filenames.
Everything will now handle long filename pasting from parent -> Paste
(It wasn't handling this at all before)
Everything will now handle long filename pasting without a hdrop, instead using the Item ID List Array.
(Should help cutting/copying from Explorer and pasting into Everything)
Everything will now handle long filename pasting from parent -> Paste
(It wasn't handling this at all before)
Everything will now handle long filename pasting without a hdrop, instead using the Item ID List Array.
(Should help cutting/copying from Explorer and pasting into Everything)
Re: LFN: Parent Paste pastes SFN & leaves dead wood
How did I miss 1301 (& 1302)?
(Below might all be immaterial (at this point).)
Anyhow, just in case there might be something in here (below) - which I ran into (yesterday) [& as I've yet to test 1301..1032...]...
LFN
path = 108
name = 183
tot: = 291
wanting to delete (to $recycle.bin)
Windows complained (what's new)
i shorted the name-part, a bunch (from orig 255), but still windows complained
figured i'd CUT the file & see what "Parent -> Paste" might do to help get
the file to a "higher" (shorter) part of the directory path
(i've been confused when doing similar with 'Rename' & this confused me too)
after a number of "same directory", & then various Windows (i'm prettty sure)
messages about "it can't do" [too], thought it was time to see what i might
be able to do in a different manner...
so i went to go to the directory in question, but "Windows" can't change to it
(when given the full path+name), so i send it (it being Salamander) the path
only, & that is fine, & the expected file /is/ there.
but, through all of that, if i now attempt to "open" the file, via Everything,
i get a (Windows) message, "Windows cannot find... Make sure you typed the
name correctly, and then try again."
so, whatever (torturous) route i just went through, Everything (on attempted
open of the file) is no longer sending the SFN for the particular file, at
present.
note below, the "param:" part (below):
exec: shellexecute file:Y:\...
...
...
...[END OF FILENAME] param:
(END OF FILENAME, was the end of the file name, followed by a space, then
the word, param:.)
AH! (kind of) forget what i said above, what actually did happen is that,
heh, something did happen, a SFN named file did get created, in a shorter
part of the path, but the SFN was not enough for me to realize that that
anything had happened (i.e., the SFN did not match my search, so i never
saw it), so this is actually just a bit of deja vue
had i realized, remembered, expected, that a SFN was created, it would have
been easier to "fix" (so rename to longer, but not too long, name, & with
the shorter path-part, i should then be able to delete... fun .)
(& so the reason that the exec: fails is because the file i'm trying to
"exec" is "deadwood" - it ain't there. what is actually in the particular
directory is an edited version of said file - also with a LFN, so what i
was seeing was actually the edited file & not what i was "clicking on"
from withing Everything)
(& doesn't it figure, that as i am writing this out, what starts playing?
- well, not exactly Crosby, Stills, Nash & Young - Deja Vu,
but Neil Young - Ohio. i'll consider that, close enough .)
(there, renamed longer & deleted .)
AH, GUSS WHAT ELSE, hard deleting a LFN (255 char name-part),
- even from a short path (c:/out/) does the same thing.
it deleted the file, but left deadwood (in Everything).
(Below might all be immaterial (at this point).)
Anyhow, just in case there might be something in here (below) - which I ran into (yesterday) [& as I've yet to test 1301..1032...]...
LFN
path = 108
name = 183
tot: = 291
wanting to delete (to $recycle.bin)
Windows complained (what's new)
i shorted the name-part, a bunch (from orig 255), but still windows complained
figured i'd CUT the file & see what "Parent -> Paste" might do to help get
the file to a "higher" (shorter) part of the directory path
(i've been confused when doing similar with 'Rename' & this confused me too)
after a number of "same directory", & then various Windows (i'm prettty sure)
messages about "it can't do" [too], thought it was time to see what i might
be able to do in a different manner...
so i went to go to the directory in question, but "Windows" can't change to it
(when given the full path+name), so i send it (it being Salamander) the path
only, & that is fine, & the expected file /is/ there.
but, through all of that, if i now attempt to "open" the file, via Everything,
i get a (Windows) message, "Windows cannot find... Make sure you typed the
name correctly, and then try again."
so, whatever (torturous) route i just went through, Everything (on attempted
open of the file) is no longer sending the SFN for the particular file, at
present.
note below, the "param:" part (below):
exec: shellexecute file:Y:\...
...
...
...[END OF FILENAME] param:
(END OF FILENAME, was the end of the file name, followed by a space, then
the word, param:.)
AH! (kind of) forget what i said above, what actually did happen is that,
heh, something did happen, a SFN named file did get created, in a shorter
part of the path, but the SFN was not enough for me to realize that that
anything had happened (i.e., the SFN did not match my search, so i never
saw it), so this is actually just a bit of deja vue
had i realized, remembered, expected, that a SFN was created, it would have
been easier to "fix" (so rename to longer, but not too long, name, & with
the shorter path-part, i should then be able to delete... fun .)
(& so the reason that the exec: fails is because the file i'm trying to
"exec" is "deadwood" - it ain't there. what is actually in the particular
directory is an edited version of said file - also with a LFN, so what i
was seeing was actually the edited file & not what i was "clicking on"
from withing Everything)
(& doesn't it figure, that as i am writing this out, what starts playing?
- well, not exactly Crosby, Stills, Nash & Young - Deja Vu,
but Neil Young - Ohio. i'll consider that, close enough .)
(there, renamed longer & deleted .)
AH, GUSS WHAT ELSE, hard deleting a LFN (255 char name-part),
- even from a short path (c:/out/) does the same thing.
it deleted the file, but left deadwood (in Everything).
Code: Select all
Everything
Version 1.5.0.1300a (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 01440614, current focus 01440614
WM_ACTIVATE 00000001 00000000, lastfocus 01440614, current focus 00000000
FOCUS 0
FOCUS restore
add nav andy
add nav andy
COMMAND 41000
selection: 1/1: Y:\...
exec: first expr
exec: command $exec("%1")
exec: fullfilename Y:\...
exec: depth 0
exec: exec "%1")
exec: depth 1
exec: got "Y:\...
exec: shellexecute file:Y:\...
...
...
...[END OF FILENAME] param:
VERB 00000000
Enter ShellExecute Y:\...
WM_ACTIVATE 00000000 021b0534, lastfocus 01440614, current focus 01440614
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 1 147dae40
PIPE READ 8
update index E:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 344
PIPE READ 0 352
USN DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE READ 8
USN DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
USN CLOSE DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
PIPE READ 8
read usn journal E: in 0.014466 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 95
PIPE READ 0 103
PIPE READ 8
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 65
PIPE READ 0 73
PIPE READ 8
updated E: in 0.009179 seconds
resume ntfs monitor 1
PIPE WRITE 33 52
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
processed 1 usn records in 0.000626 seconds
PIPE READ 8
PIPE READ 0 8
DB_WAIT: _db_journal_notification_event_proc waited 0.016153 seconds
PIPE READ 8
processed 1 usn records in 0.000073 seconds
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waiting for _db
_monitor_ntfs_process_fd_update_events_thread_proc...
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waited 0.001342
seconds
WM_CHANGECBCHAIN 0 1 00030256 00030256
WM_ACTIVATE 00000001 021b0534, lastfocus 01440614, current focus 021b0534
FOCUS 0
FOCUS restore
add nav andy
add nav andy
Leave ShellExecute 0
ShellExecuteExW(): GetLastError(): 2: failed to execute Y:\...
sub buf killed
add nav andy
set 1 run history in 0.000183 seconds
exec: main thread regained focus
WM_ACTIVATE 00000000 00000000, lastfocus 01440614, current focus 01440614
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Thanks for the bug report therube,
It sounds like the rename used the old path + short name, instead of the short path + long basename.
This will cause the deadwood issue.
If you notice this again, could you please check your Index Journal (Index -> Index Journal).
Could you please send the original filename to support@voidtools.com
I have found an issue when the file is on the desktop which will be fixed in the next alpha update.
It sounds like the rename used the old path + short name, instead of the short path + long basename.
This will cause the deadwood issue.
If you notice this again, could you please check your Index Journal (Index -> Index Journal).
Could you please send the original filename to support@voidtools.com
I have found an issue when the file is on the desktop which will be fixed in the next alpha update.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Everything 1.5.0.1304a fixes an issue with LFNs on the desktop.
Previously, Everything would not be able to create a shell item id list to a LFN on the desktop.
Previously, Everything would not be able to create a shell item id list to a LFN on the desktop.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Haven't run into a need for a lot of Parent -> Paste issues of late, more often moving a file from some deep subdirectory to a level, level, level, higher directory, kind of thing. In any case, both situations have been working fine (since 1302).Everything will now handle long filename pasting from parent -> Paste
Re: LFN: Parent Paste pastes SFN & leaves dead wood
1305
cannot Parent -> Paste a "LFN" to >1 directory
(you can Paste, singularly, to a /single/ directory at a time)
when attempting to Paste to >1 directory,
that thing called Windows rears its head
so it's a no go
(source) "LFN", in this case is "only" 249 chars; path 7, namepart 242
(destination) path+name would be 249+19 or 21, so i guess that where things fart
cannot Parent -> Paste a "LFN" to >1 directory
(you can Paste, singularly, to a /single/ directory at a time)
when attempting to Paste to >1 directory,
that thing called Windows rears its head
so it's a no go
(source) "LFN", in this case is "only" 249 chars; path 7, namepart 242
(destination) path+name would be 249+19 or 21, so i guess that where things fart
Code: Select all
Everything
Version 1.5.0.1305a (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 01e902f8, current focus 01e902f8
WM_ACTIVATE 00000001 00000000, lastfocus 01e902f8, current focus 00000000
FOCUS 0
FOCUS restore
add nav horse blue sadd
add nav horse blue sadd
COMMAND 40021
add nav horse blue sadd
WM_ACTIVATE 00000000 00000000, lastfocus 01e902f8, current focus 01e902f8
WM_ACTIVATE 00000001 00000000, lastfocus 01e902f8, current focus 00000000
FOCUS 0
FOCUS restore
add nav horse blue sadd
add nav horse blue sadd
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 3 120002b0
PIPE READ 8
ENTER THREAD 010df050
update index E:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 344
PIPE READ 0 352
USN DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE READ 8
USN DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
USN CLOSE DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
PIPE READ 8
read usn journal E: in 0.018321 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 95
PIPE READ 0 103
PIPE READ 8
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 65
PIPE READ 0 73
PIPE READ 8
updated E: in 0.009594 seconds
resume ntfs monitor 3
PIPE WRITE 33 52
DB_WAIT: db_query_get_result_count waiting for _db_monitor_ntfs_process_fd_updat
e_events_thread_proc...
ENTER THREAD 010e0450
PIPE READ 8
PIPE READ 0 8
processed 0 usn records in 0.000001 seconds
PIPE READ 8
DB_WAIT: db_query_get_result_count waited 0.008374 seconds
ENTER THREAD 010e0450
DB_WAIT: db_query_get_result_count waiting for _db_monitor_ntfs_process_fd_updat
e_events_thread_proc...
processed 0 usn records in 0.000000 seconds
DB_WAIT: db_query_get_result_count waited 0.003391 seconds
ENTER THREAD 010e0450
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
processed 1 usn records in 0.000106 seconds
DB_WAIT: _db_journal_notification_event_proc waited 0.002803 seconds
ENTER THREAD 010e0450
DB_WAIT: db_query_get_result_count waiting for _db_monitor_ntfs_process_fd_updat
e_events_thread_proc...
processed 0 usn records in 0.000000 seconds
DB_WAIT: db_query_get_result_count waited 0.003827 seconds
ENTER THREAD 010e0450
DB_WAIT: db_query_get_result_count waiting for _db_monitor_ntfs_process_fd_updat
e_events_thread_proc...
processed 0 usn records in 0.000000 seconds
DB_WAIT: db_query_get_result_count waited 0.004043 seconds
ENTER THREAD 010e0450
processed 1 usn records in 0.000038 seconds
DB_WAIT: db_query_get_result_count waiting for _db_monitor_ntfs_process_fd_updat
e_events_thread_proc...
DB_WAIT: db_query_get_result_count waited 0.002327 seconds
TTN_SHOW 347 567 - 2 1, 1429 x 20
TTN_POP
ENTER ACTION
LEAVE ACTION
TTN_SHOW 347 567 - 2 1, 1429 x 20
TTN_POP
ENTER ACTION
LEAVE ACTION
ENTER ACTION
add nav horse blue sadd
_ui_shell_IDataObjectAsyncCapability_create
ParseDisplayName W:\I\III\HORSE.BAK.I\..... ..... .... ...... ... ........
..... ..., .... ....... ....... .... ...... ...... .... .. ... & ..... ......
....., ...... ...... ..... .... ..... ... & ...... ..... ...-...-003-.......
=..-......... (B4 CUT).mpg
pidl focus 169709b0
2 pidls
get menu pidls: 2
_fndfmcb 3 00000000 00000000
cdfmc2 00000000 0000040a 00000726 00000732 000007c2
got menu 139dea08
menu type 1
menu type 3
QueryContextMenu...
_fndfmcb 18 00000010 0016ee78
_fndfmcb 1 00000010 0016ee7c
_fndfmcb 17 00000010 0016ee7c
_fndfmcb 10 00000010 0016ee7c
QueryContextMenu 0000005e
track menu 18090835
default 32777
_fndfmcb 8 18090835 0000001c
menu count 32
menu item info fail 87
00000000
wid 8: 86 (00000055)
VERB open
00000000
wid 8: 87 (00000056)
VERB HashMyFiles
00000000
wid 9: 89 (00000058)
VERB sandbox
00000000
wid 10: 90 (00000059)
VERB VirusTotal
80070057
80070057
80070057
80070057
80070057
00000000
wid 19: 78 (0000004d)
VERB PickLinkSource
80070057
menu item info fail 87
80070057
00000000
wid 23: 25 (00000018)
VERB cut
00000000
wid 24: 26 (00000019)
VERB copy
menu item info fail 87
00000000
wid 26: 17 (00000010)
VERB link
00000000
wid 27: 18 (00000011)
VERB delete
00000000
wid 28: 19 (00000012)
VERB rename
80070057
00000000
wid 30: 20 (00000013)
VERB properties
rem dbl sep
_fndfmcb 8 12060ad7 0000001c
idCommand 32771
_fndfmcb 4 0000001b 00000000
COMMAND 42424
shellexecute invoke I:\III\HORSE.BAK.I
WM_ACTIVATE 00000000 02e20550, lastfocus 01e902f8, current focus 01e902f8
WM_ACTIVATE 00000001 00000000, lastfocus 01e902f8, current focus 00000000
FOCUS 0
FOCUS restore
add nav horse blue sadd
add nav horse blue sadd
shellexecute invoke W:\I\III\HORSE.BAK.I
WM_ACTIVATE 00000000 01aa0996, lastfocus 01e902f8, current focus 01e902f8
WM_ACTIVATE 00000001 00000000, lastfocus 01e902f8, current focus 00000000
FOCUS 0
FOCUS restore
add nav horse blue sadd
add nav horse blue sadd
LEAVE ACTION
WM_ACTIVATE 00000000 00000000, lastfocus 01e902f8, current focus 00000000
WM_ACTIVATE 00000001 00000000, lastfocus 01e902f8, current focus 00000000
FOCUS 0
FOCUS restore
add nav horse blue sadd
add nav horse blue sadd
WM_ACTIVATE 00000000 00000000, lastfocus 01e902f8, current focus 01e902f8
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Thank you for the bug report therube,
This issue will be fixed in the next alpha update.
This issue will be fixed in the next alpha update.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Actually what must have been happening was...cannot Parent -> Paste a "LFN" to >1 directory
(you can Paste, singularly, to a /single/ directory at a time)
when attempting to Paste to >1 directory,
that thing called Windows rears its head
so it's a no go
(source) "LFN", in this case is "only" 249 chars; path 7, namepart 242
(destination) path+name would be 249+19 or 21, so i guess that where things fart
(but don't quote me on that )
the "LFN" that i was wanting to Paste
(it would be a "LFN" /to Windows/ due to the name part + (destination) path part being > 254)
was /i believe/ actually not being sent as a LFN, but instead as a SFN
& that SFN happened, by chance, to be causing an overwrite condition on the (destination) end
& that, /i think - now i'm not so sure ?/ is what caused the issue...
^--- maybe not ?
Re: LFN: Parent Paste pastes SFN & leaves dead wood
(Aside from just above, below is what happens.)
LFN, name part 254, Parent -> Paste to >1 destination,
results in SFN being pasted.
Pasted to 1 destination directory at a time,
works as expected.
LFN, name part 254, Parent -> Paste to >1 destination,
results in SFN being pasted.
Pasted to 1 destination directory at a time,
works as expected.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Everything currently doesn't handle LFN pastes when pasting to multiple directories.
This should be fixed in the next alpha update.
This should be fixed in the next alpha update.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Likely related, so...
i have the same exact file name, in two different directories,
yes same... name is made up of alphanum + other stuff; -~&^[]
no big deal...
name part, 236
path part, 21 or 23 chars (I:/III/... or W:/I/III/...)
so in tot, 257 or 259, both of which are then "LFN"
(are they LFN? name-part must be < 255, regardless.
so is it 254 or 254..259 or 260. eh, don't you hate LFN .)
now the odd thing...
"SendTo" XXhash.bat
> Error: Could not open 'I:/III/...'
^- this is with the /shorter/ 257
& what actually happens here, is that the name-part is being broken (separated)
at the <sp> in the filename, with each space separated part being sent separately
to XXhash. Error: Could not open '-'. Error: Could not open 'And'. Error: ...
"SendTo" XXhash.bat
> e1f602588478c100 W:\I\III\TSTSOS~1\...
^- this is with the /longer/ 259
IOW, in this instance, a SFN /basename/ dir-part was being sent (which has to be
from Everything), & that, along with (as it was) a "SFN" name-part, completed
successfully (hash returned)
in the 257 case, the the longer basename dir-part was sent, along with the "SFN"
name-part (a "LFN" in total), & that failed to parse. (XXhash does not handle LFN)
FcHash (which does handle LFN) reacts similarly.
"I:/III/..." not found
vs.
W:\I\III\TSTSOS~1\ :
xxh3 <0c1a21d61b10784ffedc965eb9d07cdb>: ...
basename = 8 chars in 8.3 situation
basename = 14 chars in non-8.3
so 6 char diff, which brings the path+name down to 251 or 253, depending
so in one case, 259 total len, Everything (& i presume it is Everything)
is sending a SFN basename part of the dir-path, along with a "long" but
still "SFN" name-part, & that succedes <sp>
& in 2nd case, 257 total len, Everything (& i presume it is Everything)
is not intervening, so the shorter total len, actually fails (where the
longer worked)
(somewhere before i believe i mentioned that you kind of have to check
both ends; path-part + name-part, both separately, & together, to
perhaps ? have a more complete picture of what might or might not be
needed to be sent [in order to bypass brain-dead limitations of Windoze].
after all it's only 2022... maybe, just maybe, in the year 2525, if man
is still alive, if woman can survive, they may find... a workable
Windoze )
note: that this is with 'SendTo'.
direct from a command line, both xxhash.exe & fchash.exe complete
successfully on the shorter, 257, I:/III/...
direct from a command line, on the longer, 259, xxhash.exe fails,
where fchash.exe is successful.
in both cases, to the .exe directly, no 8.3 (or any other "SFN")
is involved.
XXhash.bat:
XXhash64-FC.BAT
And what all brought this about was that MI_COMPARE.bat: hung - using CPU
when I went to compare a set of files - which I've never had happen before.
There where times (LFN or similar, related) where it couldn't compare a
set of files, but never did it hang, oddly, & eat CPU.
Actually, the hang was with MediaInfo_CL, so I should be able to...
Nope, that worked, calling mediainfo_cl.exe directly - both with the 8.3
& the longer basename (directory) part. I wasn't expecting that...
mi.exe i:/iii/... (both 8.3 & longer basename succeded)
mi.exe w:/i/iii/... (in this case, 8.3 basename did work, where longer basename
returned nothing. MediaInfo does not handle LFN either.)
---
Ah, so that's it.
returns (after you break out of the "hang":
And the "-" comes from where?
& %1 was set to "BFI"
> MediaInfo_CL.exe BFI
is "valid", just won't return anything meaningful because "BFI" does not exist
&&
& %2 was set to "-"
> MediaInfo_CL.exe -
& that "hangs" MediaInfo_CL.exe, eats CPU, & sits there...
neat.
(now, just what was i doing before those last few intermissions.
i mean aside from talking to the cat & the fox.)
(He, happens to call it "MediaInfo.exe". I happen to call it "MediaInfo_CL.exe" - to differentiate it from the same named GUI version. And look, there's an update out today, 3-31-2022.)
i have the same exact file name, in two different directories,
yes same... name is made up of alphanum + other stuff; -~&^[]
no big deal...
name part, 236
path part, 21 or 23 chars (I:/III/... or W:/I/III/...)
so in tot, 257 or 259, both of which are then "LFN"
(are they LFN? name-part must be < 255, regardless.
so is it 254 or 254..259 or 260. eh, don't you hate LFN .)
now the odd thing...
"SendTo" XXhash.bat
> Error: Could not open 'I:/III/...'
^- this is with the /shorter/ 257
& what actually happens here, is that the name-part is being broken (separated)
at the <sp> in the filename, with each space separated part being sent separately
to XXhash. Error: Could not open '-'. Error: Could not open 'And'. Error: ...
"SendTo" XXhash.bat
> e1f602588478c100 W:\I\III\TSTSOS~1\...
^- this is with the /longer/ 259
IOW, in this instance, a SFN /basename/ dir-part was being sent (which has to be
from Everything), & that, along with (as it was) a "SFN" name-part, completed
successfully (hash returned)
in the 257 case, the the longer basename dir-part was sent, along with the "SFN"
name-part (a "LFN" in total), & that failed to parse. (XXhash does not handle LFN)
FcHash (which does handle LFN) reacts similarly.
"I:/III/..." not found
vs.
W:\I\III\TSTSOS~1\ :
xxh3 <0c1a21d61b10784ffedc965eb9d07cdb>: ...
basename = 8 chars in 8.3 situation
basename = 14 chars in non-8.3
so 6 char diff, which brings the path+name down to 251 or 253, depending
so in one case, 259 total len, Everything (& i presume it is Everything)
is sending a SFN basename part of the dir-path, along with a "long" but
still "SFN" name-part, & that succedes <sp>
& in 2nd case, 257 total len, Everything (& i presume it is Everything)
is not intervening, so the shorter total len, actually fails (where the
longer worked)
(somewhere before i believe i mentioned that you kind of have to check
both ends; path-part + name-part, both separately, & together, to
perhaps ? have a more complete picture of what might or might not be
needed to be sent [in order to bypass brain-dead limitations of Windoze].
after all it's only 2022... maybe, just maybe, in the year 2525, if man
is still alive, if woman can survive, they may find... a workable
Windoze )
note: that this is with 'SendTo'.
direct from a command line, both xxhash.exe & fchash.exe complete
successfully on the shorter, 257, I:/III/...
direct from a command line, on the longer, 259, xxhash.exe fails,
where fchash.exe is successful.
in both cases, to the .exe directly, no 8.3 (or any other "SFN")
is involved.
XXhash.bat:
Code: Select all
@echo off
xxhsum.exe %*
pause
Code: Select all
@echo off
FcHash.exe --xxh3 %*
pause
Code: Select all
Everything
Version 1.5.0.1305a (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 019b0a44, current focus 019b0a44
WM_ACTIVATE 00000001 00000000, lastfocus 019b0a44, current focus 00000000
FOCUS 0
FOCUS restore
add nav suffix:orim
add nav suffix:orim
TTN_SHOW 465 653 - 2 1, 1453 x 20
TTN_POP
ENTER ACTION
add nav suffix:orim
_ui_shell_IDataObjectAsyncCapability_create
ParseDisplayName .:....................... - ... ..... ... ......... - .....-...
. ... .... ...... ....... ..... .... ...... ..... ..... .... ....-2.. ...., ..
... ......-..... ....... & .......-.............~................-..........-.95
854182-.177546568-.78980757...4....
pidl focus from path 16935528
pidl focus 16935528
1 pidls
get menu pidls: 1
cdfmc2 00000000 00000000 00000000 00000000 00000000
got menu 16d7ac30
menu type 1
menu type 3
QueryContextMenu...
QueryContextMenu 0000006a
track menu 296f0315
default 32791
menu count 34
menu item info fail 87
00000000
wid 8: 101 (00000064)
VERB open
00000000
wid 8: 102 (00000065)
VERB MediaInfo
00000000
wid 9: 103 (00000066)
VERB HashMyFiles
00000000
wid 10: 105 (00000068)
VERB sandbox
00000000
wid 11: 106 (00000069)
VERB VirusTotal
80070057
80070057
80070057
00000000
wid 18: 95 (0000005e)
VERB PickLinkSource
menu item info fail 87
00000000
wid 21: 28 (0000001b)
VERB PreviousVersions
80070057
menu item info fail 87
80070057
00000000
wid 25: 25 (00000018)
VERB cut
00000000
wid 26: 26 (00000019)
VERB copy
menu item info fail 87
00000000
wid 28: 17 (00000010)
VERB link
00000000
wid 29: 18 (00000011)
VERB delete
00000000
wid 30: 19 (00000012)
VERB rename
80070057
00000000
wid 32: 20 (00000013)
VERB properties
rem dbl sep
wmenuhelp 00000000
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 00000000
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
idCommand 55
using shell implementation
invoke hres 00000000
LEAVE ACTION
WM_ACTIVATE 00000000 00000000, lastfocus 019b0a44, current focus 019b0a44
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 3 120002b0
PIPE READ 8
ENTER THREAD 010df050
update index E:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 320
PIPE READ 0 328
USN DATA_TRUNCATION XXHSUM.EXE-89EB41FB.pf
PIPE READ 8
USN DATA_EXTEND DATA_TRUNCATION XXHSUM.EXE-89EB41FB.pf
USN CLOSE DATA_EXTEND DATA_TRUNCATION XXHSUM.EXE-89EB41FB.pf
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
PIPE READ 8
read usn journal E: in 0.001765 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 93
PIPE READ 0 101
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 65
PIPE READ 0 73
PIPE READ 8
updated E: in 0.001129 seconds
resume ntfs monitor 3
PIPE WRITE 33 52
ENTER THREAD 010e0450
PIPE READ 8
PIPE READ 0 8
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
processed 1 usn records in 0.000176 seconds
PIPE READ 8
DB_WAIT: _db_journal_notification_event_proc waited 0.000505 seconds
ENTER THREAD 010e0450
processed 1 usn records in 0.000020 seconds
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waiting for _db
_monitor_ntfs_process_fd_update_events_thread_proc...
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waited 0.000199
seconds
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 3 120002b0
PIPE READ 8
ENTER THREAD 010df050
update index E:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 344
PIPE READ 0 352
USN DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE READ 8
USN DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
USN CLOSE DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
read usn journal E: in 0.003759 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 95
PIPE READ 0 103
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 65
PIPE READ 0 73
PIPE READ 8
updated E: in 0.002240 seconds
resume ntfs monitor 3
PIPE WRITE 33 52
ENTER THREAD 010e0450
PIPE READ 8
PIPE READ 0 8
processed 2 usn records in 0.000257 seconds
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
DB_WAIT: _db_journal_notification_event_proc waited 0.001101 seconds
PIPE READ 8
WM_ACTIVATE 00000001 00000000, lastfocus 019b0a44, current focus 00000000
FOCUS 0
FOCUS restore
add nav suffix:orim
add nav suffix:orim
WM_ACTIVATE 00000000 00000000, lastfocus 019b0a44, current focus 019b0a44
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 3 120002b0
PIPE READ 8
ENTER THREAD 010df050
update index E:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 656
PIPE READ 0 664
USN DATA_TRUNCATION CMD.EXE-F0053CFF.pf
PIPE READ 8
USN DATA_EXTEND DATA_TRUNCATION CMD.EXE-F0053CFF.pf
USN CLOSE DATA_EXTEND DATA_TRUNCATION CMD.EXE-F0053CFF.pf
USN DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
USN DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
USN CLOSE DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
PIPE READ 8
read usn journal E: in 0.028365 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 87
PIPE READ 0 95
PIPE READ 8
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 65
PIPE READ 0 73
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 95
PIPE READ 0 103
PIPE READ 8
updated E: in 0.016576 seconds
resume ntfs monitor 3
PIPE WRITE 33 52
ENTER THREAD 010e0450
PIPE READ 8
PIPE READ 0 8
processed 1 usn records in 0.000685 seconds
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
PIPE READ 8
DB_WAIT: _db_journal_notification_event_proc waited 0.005382 seconds
ENTER THREAD 010e0450
processed 3 usn records in 0.000204 seconds
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waiting for _db
_monitor_ntfs_process_fd_update_events_thread_proc...
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waited 0.002476
seconds
WM_ACTIVATE 00000001 00000000, lastfocus 019b0a44, current focus 00000000
FOCUS 0
FOCUS restore
add nav suffix:orim
add nav suffix:orim
TTN_SHOW 465 674 - 2 1, 1453 x 20
TTN_POP
ENTER ACTION
LEAVE ACTION
ENTER ACTION
add nav suffix:orim
_ui_shell_IDataObjectAsyncCapability_create
ParseDisplayName .:......................... - ... ..... ... ......... - .....-.
... ... .... ...... ....... ..... .... ...... ..... ..... .... ....-2.. ....,
..... ......-..... ....... & .......-.............~................-..........-.
95854182-.177546568-.78980757...4....
pidl focus from path 13492980
pidl focus 13492980
1 pidls
get menu pidls: 1
cdfmc2 00000000 00000000 00000000 00000000 00000000
got menu 16d7ac30
menu type 1
menu type 3
QueryContextMenu...
QueryContextMenu 0000006a
track menu 0e3a0a4d
default 32798
menu count 34
menu item info fail 87
00000000
wid 8: 101 (00000064)
VERB open
00000000
wid 8: 102 (00000065)
VERB MediaInfo
00000000
wid 9: 103 (00000066)
VERB HashMyFiles
00000000
wid 10: 105 (00000068)
VERB sandbox
00000000
wid 11: 106 (00000069)
VERB VirusTotal
80070057
80070057
80070057
00000000
wid 18: 95 (0000005e)
VERB PickLinkSource
menu item info fail 87
00000000
wid 21: 28 (0000001b)
VERB PreviousVersions
80070057
menu item info fail 87
80070057
00000000
wid 25: 25 (00000018)
VERB cut
00000000
wid 26: 26 (00000019)
VERB copy
menu item info fail 87
00000000
wid 28: 17 (00000010)
VERB link
00000000
wid 29: 18 (00000011)
VERB delete
00000000
wid 30: 19 (00000012)
VERB rename
80070057
00000000
wid 32: 20 (00000013)
VERB properties
rem dbl sep
wmenuhelp 00000000
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 00000000
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80070057
amenuhelp 80070057
wmenuhelp 00000000
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
wmenuhelp 80004001
amenuhelp 80004001
idCommand 55
using shell implementation
invoke hres 00000000
LEAVE ACTION
WM_ACTIVATE 00000000 00000000, lastfocus 019b0a44, current focus 019b0a44
WM_ACTIVATE 00000001 00000000, lastfocus 019b0a44, current focus 00000000
FOCUS 0
FOCUS restore
add nav suffix:orim
add nav suffix:orim
WM_ACTIVATE 00000000 00000000, lastfocus 019b0a44, current focus 019b0a44
And what all brought this about was that MI_COMPARE.bat: hung - using CPU
when I went to compare a set of files - which I've never had happen before.
There where times (LFN or similar, related) where it couldn't compare a
set of files, but never did it hang, oddly, & eat CPU.
Actually, the hang was with MediaInfo_CL, so I should be able to...
Nope, that worked, calling mediainfo_cl.exe directly - both with the 8.3
& the longer basename (directory) part. I wasn't expecting that...
mi.exe i:/iii/... (both 8.3 & longer basename succeded)
mi.exe w:/i/iii/... (in this case, 8.3 basename did work, where longer basename
returned nothing. MediaInfo does not handle LFN either.)
Code: Select all
:: MediaInfo _ command_com line COMPARATOR with CALL to Salamander's File Comparator
@echo off
set X_TEMP_PATH=%PATH%
path %PATH%;C:\DEV\CODECS\MediaInfo_CL\;
set OUT1=C:\OUT\MI_COMPARE1.TXT
set OUT2=C:\OUT\MI_COMPARE2.TXT
echo FILE 1: > %OUT1%
echo %1 >> %OUT1%
echo. >> %OUT1%
echo FILE 2: > %OUT2%
echo %2 >> %OUT2%
echo. >> %OUT2%
:: originally, the above echo were not there, & if for some reason the MI failed,
:: like from a too long PATH, kind of thing
:: both the files ending up with nothing in them, so they would compare as
:: "equal", & they "were", except it was comparing against "nothing" instead
:: of actually returned valid results of the MI command
:: anyhow, MI does have exit codes; 0=success, 1=failure, but for some reason
:: depending on, not sure, file order (which one "first") or whatever, again
:: valid result may not have been given
:: with the echo's, at the least there will be some diffs to the files, so the
:: compare, while still not of relevant data, at least will "not compare" &
:: so will point out diffs, & then it's like, ah, what's going on here
:: so at least you know something is up, instead of "falsely" being told, oh,
:: your files compare, exactly [wrong]
C:\DEV\CODECS\MediaInfo_CL\MediaInfo_CL.exe %1 >> %OUT1%
:: if errorlevel 1 echo FILE 1: MEDIAINFO DETECTED FAILURE, %1 >> %OUT1%
:: set errorlevel=
C:\DEV\CODECS\MediaInfo_CL\MediaInfo_CL.exe %2 >> %OUT2%
if errorlevel 1 echo FILE 2: MEDIAINFO DETECTED FAILURE, %2 >> %OUT2%
:: for some reason, these (TWO) errorlevel checks were not always returning
:: expected results, so i changed to the 'echo' method (above) which "forces"
:: diffs into %OUT_%, so a failure won't compare equally
"C:\WLIB\Altap Salamander 40\plugins\filecomp\fcremote.exe" %OUT1% %OUT2%
set PATH=%X_TEMP_PATH%
set X_TEMP_PATH=
---
Ah, so that's it.
Code: Select all
MediaInfo_CL.exe -
Code: Select all
General
File size : 0.00 Byte
And it so happens that the filename starts with "BFI -",& what actually happens here, is that the name-part is being broken (separated)
at the <sp> in the filename, with each space separated part being sent separately
& %1 was set to "BFI"
> MediaInfo_CL.exe BFI
is "valid", just won't return anything meaningful because "BFI" does not exist
&&
& %2 was set to "-"
> MediaInfo_CL.exe -
& that "hangs" MediaInfo_CL.exe, eats CPU, & sits there...
neat.
(now, just what was i doing before those last few intermissions.
i mean aside from talking to the cat & the fox.)
MediaInfo_CL.exe is the command line version of MediaInfo.*MediaInfo_CL.exe
(He, happens to call it "MediaInfo.exe". I happen to call it "MediaInfo_CL.exe" - to differentiate it from the same named GUI version. And look, there's an update out today, 3-31-2022.)
Re: LFN: Parent Paste pastes SFN & leaves dead wood
so a LFN...
- SendTo a LFN aware program is sent the LFN
- SendTo a not-LFN aware program, is sent a SFN
is that what is going on?
so, what, you check for a fail, & then resend with SFN?
- SendTo a LFN aware program is sent the LFN
- SendTo a not-LFN aware program, is sent a SFN
is that what is going on?
so, what, you check for a fail, & then resend with SFN?
Re: LFN: Parent Paste pastes SFN & leaves dead wood
259 characters is OK.so in tot, 257 or 259, both of which are then "LFN"
(are they LFN? name-part must be < 255, regardless.
so is it 254 or 254..259 or 260. eh, don't you hate LFN .)
260 or more is over the Windows Shell limit.
Technically, the limit is 260 characters, but you need 1 null terminating character.
There's an interesting limit with using Sendto:
Using Sendto will automatically add double quotes (") to filenames that contain spaces.
However, Sendto DOES NOT add double quotes (") to filenames with a length of 258 or 259 as it would cause a buffer overflow.
So if you use 'sendto' with a length of 258 or 259 and with a space in the filename, it will not be shortened (eg: C:\along~1\...) and will NOT be double quoted, which will make the filename end up being incorrectly treated as multiple files.
I don't have a good solution sorry.
Everything passes a valid filename to the shell, and the shell is trying to add quotes, but doesn't have enough buffer space.
Consider the following hack:
Code: Select all
@echo off
IF EXIST %1 (
xxhsum.exe %*
) ELSE (
xxhsum.exe "%*"
)
pause
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Just to note...
Seems that within the Everything realm, this is now working correctly.
But once you jump outside of Everything, you need to be aware of what might be happening...
1309
if you CUT a LFN (name-part 254)
& paste it
- outside of Everything
the CUT name ("generated" by Everything) is a SFN,
so a SFN gets pasted into the new location
- &, at the same time, the original LFN is left as "dead wood" (in Everything)
i suppose since Everything did the CUT, & did it as a SFN,
it was /expecting/ that it too would do the paste,
(in which case it would then have pasted the LFN)
but when done (pasted) outside of Everything,
Everything didn't realize that a pasted (& newly "created" in that respect)
/SFN/ had occured, so in its' mind, the paste of the LFN never occurred,
so the file still exists (to Everything)
(PS: other then reindex, you can "fix" it by renaming the new SFN to the (dead wood) LFN
then use Everything to cut/paste that renamed file over top of the "dead wood" file [in
its' original location] )
Seems that within the Everything realm, this is now working correctly.
But once you jump outside of Everything, you need to be aware of what might be happening...
1309
if you CUT a LFN (name-part 254)
& paste it
- outside of Everything
the CUT name ("generated" by Everything) is a SFN,
so a SFN gets pasted into the new location
- &, at the same time, the original LFN is left as "dead wood" (in Everything)
i suppose since Everything did the CUT, & did it as a SFN,
it was /expecting/ that it too would do the paste,
(in which case it would then have pasted the LFN)
but when done (pasted) outside of Everything,
Everything didn't realize that a pasted (& newly "created" in that respect)
/SFN/ had occured, so in its' mind, the paste of the LFN never occurred,
so the file still exists (to Everything)
Code: Select all
Everything
Version 1.5.0.1309a (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 02e10980, current focus 02e10980
WM_ACTIVATE 00000001 00000000, lastfocus 02e10980, current focus 00000000
FOCUS 0
FOCUS restore
COMMAND 40020
CUT isviewing 0
ParseDisplayName 80070057 C:\out\254LFN ........................................
................................................................................
................................................................................
..................................... LFN254.mp4
iscut 1
ghost selection
viewing 0
on clipboard changed 0 0 12479 1
WM_DRAWCLIPBOARD 04ce068c 00000000 0 0 1
is cut done
WM_DRAWCLIPBOARD 00260ac4 00260ac4 0 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 1 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 2 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 3 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 4 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 5 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 6 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 7 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 8 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 9 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 10 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 11 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 12 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 13 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 14 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 15 1 0
WM_DRAWCLIPBOARD 00260ac4 00260ac4 16 1 0
on clipboard changed 0 12475 12479 1
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
on clipboard changed 0 12479 12479 0
WM_ACTIVATE 00000000 00000000, lastfocus 02e10980, current focus 02e10980
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 3 0fbd8838
PIPE READ 8
update index E:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 344
PIPE READ 0 352
USN DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE READ 8
USN DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
USN CLOSE DATA_EXTEND DATA_TRUNCATION CONHOST.EXE-E6AFC9F5.pf
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
read usn journal E: in 0.001232 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 95
PIPE READ 0 103
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 65
PIPE READ 0 73
PIPE READ 8
updated E: in 0.001047 seconds
resume ntfs monitor 3
PIPE WRITE 33 52
processed 1 usn records in 0.000160 seconds
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
PIPE READ 8
PIPE READ 0 8
DB_WAIT: _db_journal_notification_event_proc waited 0.000382 seconds
PIPE READ 8
processed 1 usn records in 0.000017 seconds
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waiting for _db
_monitor_ntfs_process_fd_update_events_thread_proc...
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waited 0.000082
seconds
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 0 0ec0ec40
PIPE READ 8
update index C:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 272
PIPE READ 0 280
USN RENAME_OLD_NAME 254LFN~1.MP4
PIPE READ 8
USN RENAME_NEW_NAME 254LFN~1.MP4
USN CLOSE RENAME_NEW_NAME 254LFN~1.MP4
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
read usn journal C: in 0.001950 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 55
PIPE READ 0 63
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 73
PIPE READ 0 81
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 51
PIPE READ 0 59
PIPE READ 8
updated C: in 0.001589 seconds
resume ntfs monitor 0
PIPE WRITE 33 52
DB_WAIT: _db_journal_notification_event_proc waiting for _db_monitor_ntfs_proces
s_fd_update_events_thread_proc...
processed 2 usn records in 0.000168 seconds
PIPE READ 8
PIPE READ 0 8
DB_WAIT: _db_journal_notification_event_proc waited 0.000541 seconds
PIPE READ 8
new results 239949
ui->listview_was_focus_in_view 1
new results 704
ui->listview_was_focus_in_view 0
WM_ACTIVATE 00000001 00000000, lastfocus 02e10980, current focus 00000000
FOCUS 0
FOCUS restore
WM_ACTIVATE 00000000 00000000, lastfocus 02e10980, current focus 02e10980
then use Everything to cut/paste that renamed file over top of the "dead wood" file [in
its' original location] )
Re: LFN: Parent Paste pastes SFN & leaves dead wood
The alternative is to disable using short basenames, which will cause the paste with the Windows Shell to fail (The filename would be too long for the destination folder).
The paste will still work in Everything.
The next alpha update will disable short basenames for cut/copy.
Fow now, to disable using short basenames:
You will also be unable to open really long filenames.
The paste will still work in Everything.
The next alpha update will disable short basenames for cut/copy.
Fow now, to disable using short basenames:
- In Everything, type in the following search and press ENTER:
/shell_short_basename=0 - If successful, shell_short_basename=0 is shown in the status bar for a few seconds.
You will also be unable to open really long filenames.
Re: LFN: Parent Paste pastes SFN & leaves dead wood
(I'd much rather have LFN working, as it is, & now knowing that outside of Everything a SFN may be pasted [rather then most likely nothing at all], then to have things not even work at all.)
Re: LFN: Parent Paste pastes SFN & leaves dead wood
Everything 1.5.0.1310a disables short basenames for cut/copy.
You can still cut/copy and paste really long filenames with in Everything.
This will just prevent cut/copy and paste working in Windows Explorer.
I have put on my TODO list to add an option to disable this.
Maybe have this option disabled by default.
You can still cut/copy and paste really long filenames with in Everything.
This will just prevent cut/copy and paste working in Windows Explorer.
I have put on my TODO list to add an option to disable this.
Maybe have this option disabled by default.