| Date: | January 25, 2005 / year-entry #23 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050125-00/?p=36603 |
| Comments: | 24 |
| Summary: | If you have a file or directory that does not have a last-modified date, you may find that it causes Explorer to sort very strangely. (How do you get a file or directory with no last-modifiied date? It's hard to do; you need the help of an external file system.) Why is this? As we... |
If you have a file or directory that does not have a last-modified date, you may find that it causes Explorer to sort very strangely. (How do you get a file or directory with no last-modifiied date? It's hard to do; you need the help of an external file system.) Why is this? As we learned earlier, a sort comparison function must impose a total order in order to produce consistent results. The problem is that Explorer's comparison function mis-handles files and directories with no last-modified date. To get some more of the background behind this, you need to know about so-called "simple pidls". A simple pidl is an item ID list that refers to a file or directory that does not actually exist. The problem is that a valid file or directory with no last-modified date looks just like one of these simple pidls becauses Explorer uses the last-modified date to distinguish whether it is manipulating a real pidl or a simple one. The problems with sorting occur when it comes time to decide where in the list these "real pidls that are mistaken for simple pidls" go into the sorted list. Explorer tries to keep all folders together, but if it sees a "simple pidl" it can't tell whether that item is a folder or a file (after all, something that doesn't exist is neither a file nor a folder) and it ends up producing inconsistent comparison results. Moral of the story: Be careful with your sort functions. If you produce inconsistent results in your sort function, you will get inconsistent results in your "sorted" output. |
Comments (24)
Comments are closed. |
Somewhat on-topic, one thing that bugs me (and I don’t know if it’s strictly a Windows thing or if Unix does this too), but why on Earth can’t you change the date/times of directories? I know it’s largely useless, but I seem to recall encountering that limitation even in DOS. =)
But you can. SetFileTime()
But you can. SetFileTime() with the CreateFile() call including the GENERIC_WRITE and FILE_FLAG_BACKUP_SEMANTICS.
But you can. SetFileTime() with the CreateFile() call including the GENERIC_WRITE and FILE_FLAG_BACKUP_SEMANTICS.
PS: Someting wrong with Blogging software? This is my 4th attempt to submit.
Thanks "A", no to go see if that works under ‘9x and NT. =)
Don’t think that will work in 9x
Goes slightly OT, what interfaces you need to add your own sorting to the Explorer for the file/directory column – like Asc/Desc by name and then something else by me. Does this really require namespace extension etc? No sort of simpler hook ?
"Don’t think that will work in 9x"
How many hours of your programming career is it worth to try and get advanced features out of a 10-year-old platform? Don’t fool yourself by looking at Windows installed base, look at your potential buyers. If you’re doing it all for free because your time is valued at $0/hr, then by all means have fun with solving these 9x brain teasers.
I am happy to let software work as well as 9x/Me will let it, but I’m not going to do a bunch of extra work to recreate 10 years of Windows API progress.
Can we all make a blood pact to ignore 9x now? I have just stuck my finger with a pin and am pressing it to the screen. Please do the same and press Submit.
Thanks Raymond! This answers a question I put into your suggestion box, although I didn’t know enough at the time to explain it properly. One of our partitions was copied over from an old Novell server, and the directories were all intermingled with files, and were ‘alphabetically challenged’. Turns out, over half of these folders didn’t have modified dates.
A quick command line later (for /d %x in (*) do touch "%xfixdate.fix" && del "%xfixdate.fix") and now everything is displaying in the correct order :)
explorer often sorts "shortcut to folders" among files, instead of among folders. Is it related to this behavior?
Dave:
It’s less an issue of *wanting* to be compatible with ‘9x and more a matter of wanting to know what kind of minimum system requirements my application would require by utilizing feature X. I agree, I’m happy everything is running off of NT now and I hope ‘9x dies a quick death.
Kind of on topic, but one interesting thing I’ve noticed in Windows XP explorer is that it will load a folder with one sorting system, and then shortly after (or after a refresh) it will modify it slightly.
For an example, put the following folders somewhere and watch..:
1.0.1
1.0.12
1.0.2
It should modify it to be:
1.0.1
1.0.2
1.0.12
I do like it this way, but it is very annoying that it only changes after a few seconds, or after a refresh (and not on load-up). Much better if it was consistent.
No; shortcuts to folders *are* files.
"put the following folders somewhere and watch"
I assume that newly created or renamed files and folders are put/left in place unsorted because that makes them easier to find. Imagine if you created a new folder and then renamed it, the second you pressed enter it would "disappear" to a new location in the list because of the sort order. That would be confusing and a bit scary ("OMG, where did my folder go? I just renamed it and it’s GONE!"). You could do some sort of hokey animation showing the file moving from its old position to the new one I guess. (That was NOT a feature suggestion!).
Actually, that’s exactly what happens if you have Show in Groups turned on and auto-arrange by name. If you create a new folder, then it starts off under "N" for "New Folder", then when you type in the name you want and press Enter it gets filed under the new first letter.
Not entirely related (the more appropriate topic has been and gone, and it involves "directories" and "sort order", so I’ll risk it) but I came across some very strange "short filename" versions of directories today, and I can’t even begin to work out how the short names have been generated:
JOC971~1 Job16_001
JOC981~1 Job16_002
JOC991~1 Job16_003
JOC9A1~1 Job16_004
JOC9B1~1 Job16_005
JO846D~1 Job16_006&007
JOC9E1~1 Job16_008
JOB16_~2 Job16_009
JOB16_~3 Job16_010
JOB16_~4 Job16_011
JOD989~1 Job16_012
JOB16_~1 Job16_013
IIRC, a checksum of the long filename is used for part of the short filename if there are too many would-be-overlapping-as-short-filenames long filenames in a directory to just do the sequential ~1, ~2, ~3 etc.
"I assume that newly created or renamed files and folders […]"
It affects the folders no matter how long they have been there (but maybe just when in "Arrange in groups" mode).
In other words, the ones writing (or even designing) Explorer screwed up so badly you felt the need to publicly humiliate them (hoping they’d be fired – I sure do for the ways they destroyed the once perfectly working Explorer of Win95/NT3.51+NewShell/NT4 with the VB-ish crashing Web-ish thing (junk) we are forced to use nowadays)?
Should you ever need support for having them seen in tar and feathers on web-TV, I can likely get ~10k-40k votes from paying customers.
in response to that old ordering thingy:
The transitivity of equality condition means that you can’t use floating point with epsilon for sorting – or (for instance) creating a map/dictionary. Which… sucks sometimes.
Vorn
Anon Coward: Thank you for putting words in my mouth.
What other criteria can be used to tell a simple pidl from a valid file or dir?
Vorn
A simple pidl is just a normal pidl, but with some information set to 0. The problem is that 0 is a valid value for some of these things (e.g., no last modified time), so just by looking at a pidl you can’t really tell if it’s a simple pidl or a normal pidl with a lot of 0’s.
Shortcuts to directories aren’t always files. For example, create a directory shortcut on your Start Menu in either Windows 2000 or Windows XP. I created a shortcut to a directory called "bin" on my Start Menu:
[ben@frazzle C:Documents and SettingsAll UsersStart Menu]$ dir
Directory of C:Documents and SettingsAll UsersStart Menu
2005-01-31 16:45 <DIR> .
2005-01-31 16:45 <DIR> ..
2005-01-31 16:45 <DIR> bin
2005-01-31 01:14 <DIR> Programs
[ben@frazzle C:Documents and SettingsAll UsersStart Menu]$ dir bin
Directory of C:Documents and SettingsAll UsersStart Menubin
2005-01-31 16:45 <DIR> .
2005-01-31 16:45 <DIR> ..
2005-01-31 16:45 471 target.lnk
In this case, it creates a directory with a specially-named shortcut file and a Desktop.ini (which is hidden, of course) inside it. Strangely, this only seems to happen if you make a directory shortcut on the Start menu. Elsewhere, they are created as they were in previous versions of Windows. If you move or copy the created shortcut from the Start Menu to another directory it goes on working. It seems that the shortcut directory must also be read-only for it to work. Wacky stuff.
Fun can be had by putting one of these desktop.ini files in a normal directory along with a target.lnk shortcut and setting the directory read-only. Suddenly the directory becomes inaccessible from Explorer!
Oh, the fun things you can do with Windows Explorer.