(That's the short version of it.)
---
(I was looking at video, in particular.)
1317
fails to find (Property) 'Length'
on LFN
path = 38
name = 237
tot: = 275
no, that's not it!
that is not the reason - at least that is not the *FULL* reason
hmmm...
used FFC to copy LFN
> FFC home3412* X\
CD X
egor (open Everything in CWD)
home3412... <displays>
Salamander -> F2 home3412... -> xxx.wmv
looks like it's going to be this:
> USN RENAME_OLD_NAME HOME34~1.WMV
> PIPE READ 8
> USN RENAME_NEW_NAME xxx.wmv
> USN CLOSE RENAME_NEW_NAME xxx.wmv
where HOME34~1.WMV was in fact that said LFN
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 02951126, current focus 02951126
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
update m 29 0db0c830
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.002671 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.001510 seconds
resume ntfs monitor 29
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.000207 seconds
PIPE READ 8
PIPE READ 0 8
DB_WAIT: _db_journal_notification_event_proc waited 0.001000 seconds
PIPE READ 8
processed 1 usn records in 0.000062 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.000176
seconds
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 256
PIPE READ 0 264
USN RENAME_OLD_NAME HOME34~1.WMV
PIPE READ 8
USN RENAME_NEW_NAME xxx.wmv
USN CLOSE RENAME_NEW_NAME xxx.wmv
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 8
PIPE READ 0 16
PIPE READ 8
read usn journal T: in 0.003039 seconds
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 51
PIPE READ 0 59
PIPE WRITE 35 20
PIPE READ 8
PIPE READ 63
PIPE READ 0 71
PIPE READ 8
updated T: in 0.001716 seconds
resume ntfs monitor 36
PIPE WRITE 33 52
processed 2 usn records in 0.000250 seconds
PIPE 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...
PIPE READ 8
DB_WAIT: _db_monitor_process_fd_update_event_finished_event_proc waited 0.000623
seconds
new results 2
ui->listview_was_focus_in_view 0
if i rename back, from xxx.wmv to LFN...
MoveFile:
T:\X\xxx.wmv
to:
\\?\T:\X\home3412...
PIPE READ 8
PIPE READ 4
PIPE READ 3 12
try rename: 1:
T:\X\xxx.wmv
to:
T:\X\home3412...
update m 36 0faacbd8
PIPE READ 8
update index T:
PIPE WRITE 34 52
PIPE READ 8
PIPE READ 1160
PIPE READ 0 1168
USN RENAME_OLD_NAME xxx.wmv
PIPE READ 8
USN RENAME_NEW_NAME home3412...
USN CLOSE RENAME_NEW_NAME home3412...
(btw, renaming it back "fixes" the deadwood)
*FULL reason
- oh, not sure offhand (yet ?)
but, with /said/ LFN (when named as; home3412...)
Everything does NOT see the (Property) 'Length'
- but, if i rename LFN, home3412... to xxx.wmv
(at that point total len of 45 (a SFN)
the (Property) 'Length" /IS/ seen
now, there are plenty of other LFN
> path:len:>260
where (Property) 'Length' is seen (& then /some/ LFN where 'Length' is not seen)
(Property) 'Length' may not be seen for various reason
"corrupt" file
"partial" file (different from corrupt)
(odd) codec used (where in general the particular /container/ is otherwise fully supported)...
i'm thinking it's going to have to do with a combination of both path + name parts
& where & when the two combined become a "LFN"
(& maybe even, what was that recent relevation where "255" [or whatever that number was] was not an absolute...)
(don't you luv LFN
. i think i've said that, b4 heh.)if i drop name part length down to 226 (so total len of 264), at that point 'Length' does display
- path len of 38, allows for a maximum name len of 226 [total 264] before 'Length' "disappears"
(this is NOT an issue with the particular file - other file can be substituted with same resultes)
if i move same "working" file to its' parent (so sans X\ - a shorter path)
- path len of 36 + name 226, tot 262 - WORKS
- path len of 36 + name 229, tot 265 - FAILS
-- so again, 264 is a "magic" number
- seemingly based on Path (or did i mean /Location/
) length& if i copy said file to c:/out/ (path = 7), then i should be able to create a name len of 257
& (Property) 'Length' should be seen
& with a name len of 258, is should "disappear"
?
so much for that idea, cause i then run into the 255 limit
& at 7 + 255, while only 262, 'Length' is not seen
(have to drop down to 7 + 252, tot of 259, for 'Length' to be seen)
(yet a different file...
path 65 + name 224, tot 289 does display 'Length')
(so i didn't bring my flash drive home, saying to myself,
i'm not going to run into anything tonight
)so what... is it going to be...
if name.part <= 254-path.len = OK
if name.part > 254-path.len = FAIL
so if Location (er...) path = 38
that would mean that name.part can be 226 in order for (Property) 'Length' to work
but, it's more then just that, isn't it... ?
260 or 259 ( -path.len ) might also be in play here?
or maybe more yet again?
*HAS* to be more then just that (or something /around/ that),
LFN (or "close to" LFN) conversions (to SFN) also have to be playing in...
*HAS*
Full Path Length helps to point that out
(things like a name.part 255, path.part 172, tot 427, still works, does display 'Length')
suffice to say, at some length, Length doesn't work
(don't worry, you'll get it
)