Finding a folder whose name includes an extension?

[ChrisGreaves]

Untitled.png (37.09 KiB) Viewed 5896 times

On this grey, freezing, cloudy May Day I created a folder with the name "Folder.doc". The folder is visible in the centre of my screen shot.
Over the screenshot I have pasted a portion of my Result List which delivers zero Objects when I search for

T:\Greaves\Training\Everything ext:doc folders:

If I remove the "Folders:" modifier I see my documents, so I believe that the leading terms of the Search String is correct.

Why does everything tell me that there are no folders with an extension of "doc", and, I presume, that there are no folders with an extension of "xls" or for that matter "qwe", "rty, "uio" and so on?
Can it be that Everything sees the extension and assumes that only files have extensions?

As you have all already guessed I am thigh-deep in 'Terminology", and I claim that a folder is just a file that belongs to Windows, and that that file contains a list of files (a DOS "Directory" if you will).

That basic search

T:\Greaves\Training\Everything ext:doc folders:

delivers 98 objects
When I add "Files:" as a modifier - 98 objects.
If instead of "Files:" I add "Folders" - 0 objects.

I know that the folder "Folder.doc" exists. Even stupid old Windows File Explorer knows it exists.
There can be found good reasons for using an extension of DOC on a project folder that contains only DOCuments, and a separate folder with an extension of PNG for screen-image files, XLS for budgeting on the project, LOG for time-sheet data ...

(signed) "puzzled" of Bonavista.

[therube]

First thing,

folder:

(singular).
Then,

folder:.000

.

ext:

is for file names (aka, Name), rather then for directory names (aka, Path).

[NotNull]

If folders can have extension or not is an ongoing debate. Even Windows itself is unsure: CMD and PowerShell insist they can; Explorer thinks they can't.
Everything is in "camp Explorer".

[void]

ext: will match files only.

Please try the following search:
*.doc folder:

[ChrisGreaves]

First thing,

folder:

(singular).

Thanks therube. I was looking at the wiki

Code: Select all

folder:
folders:
nofolderonly:	Match folders only

I haven't tried many examples, but since I can never remember whether to use the singular or the plural, I suspect that I have been using both indiscriminately
More and more, when a search String doesn't work, I play with it until I can make an example that does work, then slowly make my way back to what I think I want to do.
So I suspect that if the plural didn't work, I would have found out quite quickly that only the singular form works.

Then,

folder:.000

.

I don't understand this. I just tried

T:\Greaves\Training\Everything folder:.000 ext:doc

which returned no results. Did you mean for that "000" string to represent three decimal digits?

ext:

is for file names (aka, Name), rather then for directory names (aka, Path).

Thank you for this. I see that Void has replied so I will tackle this head-on in my reply to him.
I am still learning, but to date had seen not a post that discussed this.
Objects (in the Result List) have <identifiers> (to avoid the name/path/extent confusion), and those <identifiers> can make use of extents, and I understood the ext: modifier to specify extents!

Clearly using a folder name of ".doc" is quite legal in Windows.
Cheers, Chris

[ChrisGreaves]

If folders can have extension or not is an ongoing debate. Even Windows itself is unsure: CMD and PowerShell insist they can; Explorer thinks they can't.

NotNull, you know how much I hate to argue , but I do think that the image in my first post demonstrates that in Win11 Explorer at least, one can File, New, Folder and give it an extended name.

Untitled.png (43.1 KiB) Viewed 5853 times

I haven't tried PowerShell, but cmd answers my question "Where can I find the folder named "Folder.doc"?

Everything is in "camp Explorer".

NotNull, you know how much I hate to argue , but since Windows can locate the folder.doc in both Explorer and in cmd, I think it is not playing the game fairly.
It might be true that Everything refuses to report folders with extensions, but then my question is "why?"
My current understanding is that if I did NOT want folders with extents to be listed, then I might search for

T:\Greaves\Training\Everything ext:doc files:

Now on to Void's response ...

Cheers, Chris

[horst.epp]

Clearly using a folder name of ".doc" is quite legal in Windows.
Cheers, Chris

Some things which are still allowed by Windows are only for fools
not knowing what complications come with them.
For example, no script can distinguish folders with extensions from files
without reading the attributes of such an objects in a list.

[ChrisGreaves]

ext: will match files only.

Thanks Void. I see that now.
But why restrict the results to files-only by default? (more below)

Please try the following search:

*.doc folder:

SearchFunctions_05.png (18.34 KiB) Viewed 5840 times

Thanks Void, this works as a method for locating FOLDERS with extents of "DOC", but still the question remains, how can I locate OBJECTS (which you define as Files and Folders) with extents of "DOC"?

Below: The general structure of Everything allows users to add modifiers and all sorts of search terms to gradually reduce the number of objects in the Result List. I mean this in the sense that one first essays with "T:\Greaves" then appends another level of path to use "T:\Greaves\Training" , which reduces the number of objects in the Result List, then appends "DateModified:>=2023-04-17" to reduce the Result list still further, and finally appends "Content:debug" to end up with a short list of documents one of which will be relevant.

That is, the Result List is populated generally (583,749 objects (on my system)) and is gradually reduce by the addition of Search Terms which provokes the attrition of Objects from the Result List.

In that sense I think of adding restrictions (as extra search items) as I go. But now I learn that "ext:.doc" seems to be like a macro for the search terms "files:ext:.doc".

The search modifier "ext:" turns out be a macro for "files:ext:" (without spiraling into a recursive death!)

In the back of my mind is the fact that Everything relies on separate databases for Files and for Folders, and I wonder if this is the basis for making ext: ignore one of the databases? From the end-user's point of view, we ought not to be concerned about how many databases drive the engine, unless we truly need to know. Timing problems are an example, speed of execution.

In the Long term (and be very sure I wish you and Everything a VERY long life), a design principle that treats Search Modifiers as interchangeable components of a modular system should accelerate to proper use of Everything.
Clearly, on a very local scale (me!), this weird behaviour of ext: has slowed me down. (But only by a little bit!)

I think that this meta-level of design needs some discussion.
Thanks, Chris

[raccoon]

Hot take: There haven't been "file extensions" since the deprecation of 8.3 short filenames. They were treated very differently in FAT filesystems and now modern NTFS et al filesystems are completely agnostic about the idea of file extensions.

Want to start a debate? Should the file "image.tar.gz" show "tar.gz" under the Extension column? (hint: it only shows "gz")

Any acknowledgement of file extensions by cmd/powershell is purely for ancient backwards compatibility with 20-30 year old Batch Files. For Windows, extensions are known as File Associations, and exist for aesthetics and convenience but have no underlying structure or meaning in the filesystem. Their only use is to determine which software to open a document in by default.

Why shouldn't Folders be treated as having a file extension you ask? Because software cannot open a folder as a "document". Windows doesn't try to determine "should this folder be opened up by Microsoft Excel or Word Perfect when double-clicked?"

I recommend simply removing all dots from your folder names.

[therube]

Thanks therube. I was looking at the wiki

Didn't realize they were synonyms.

folder:.000

Would find directories that have ".000" in their filename (dirname).

I recommend simply removing all dots from your folder names.

Aside from all the directories that I have that have dots .

Code: Select all

E:\Users\RUBEN7\AppData\Local\Microsoft\Windows\History\History.IE5\
E:\Users\RUBEN7\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_vpro5.exe_cf3cde624819f6c8acec3fc28d87f2e37875746_66cf51f6\
E:\Windows\Installer\MSICC66.tmp-\
C:\Local\SANDBOX\ytDL\user\current\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\
E:\Windows\Microsoft.NET\Framework\v4.0.30319\
C:\Local\SANDBOX\CLEAN\user\current\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Avidemux 2.8 VC++ 64bits\
C:\Local\SANDBOX\EASUS\user\all\Microsoft\Windows\Start Menu\Programs\EaseUS Partition Master 15.0\
C:\Local\SANDBOX\freefileviewer\drive\E\Windows\WinSxS\x86_microsoft.vc90.openmp_1fc8b3b9a1e18e3b_9.0.21022.8_none_ecdf8c290e547f39\

[ChrisGreaves]

@VOID parts of this topic should, perhaps, be hived off to a separate topic in the General or Suggestions forum?

Hot take: There haven't been "file extensions" since the deprecation of 8.3 short filenames. They were treated very differently in FAT file systems and now modern NTFS et al file systems are completely agnostic about the idea of file extensions.

Thanks for the update raccoon. Shall we start a campaign to remove all mentions of “ext:” and extensions from Everything? I have written up a Backus-Naur Form of my version of file identifiers and you may be pleased to know that I am not too happy about extensions in general. I think of a file’s name as Diary.doc, or image.tar.gz. Basically I think of the “name” as being whatever string is lodged/listed in the folder. In old-school terminology anything except the drive and folder path.
I once knew someone whose filenames were "Diary.txt.doc.xls" because the data started off as a text file, then was migrated into a MSWord document before ending up as a budget spreadsheet. Also email to spreadsheet to document. You name it, they used it!

Want to start a debate? Should the file "image.tar.gz" show "tar.gz" under the Extension column? (hint: it only shows "gz")

A debate? I dunno ... (:lol:) Based on my understanding of DOS conventions, I would consider a file’s name extension to be any symbols to the right of the rightmost period in the file’s name. Showing only “gz” fits in with my understanding.

Any acknowledgement of file extensions by cmd/powershell is purely for ancient backwards compatibility with 20-30 year old Batch Files. For Windows, extensions are known as File Associations, and exist for aesthetics and convenience but have no underlying structure or meaning in the file system. Their only use is to determine which software to open a document in by default.

A debate? OK!!! ... (:lol:) If I have understood this, extent/extensions are whatever the French antonym of de rigeur is (imprécision, incertitude, inexactitude ...) and those of us who are modern should be using “file association”, which is more difficult to say and type than ext. And who, except me, is still using Batch Files?
However I would contest your stand that “... have no underlying structure or meaning in the file system. Their only use is to determine which software to open a document in by”. A file’s identifier is part of a file system; it is the route one takes to locate a file. Having found that file, the file system gives us a clue (via the registry (another part of the file system) nowadays) about which application should receive a copy of the file.
Using a part of a file’s identifier to associate that file with a probably useful application seems like co-habitation to me.

Why shouldn't Folders be treated as having a file extension you ask? Because software cannot open a folder as a "document". Windows doesn't try to determine "should this folder be opened up by Microsoft Excel or Word Perfect when double-clicked?"

AhHa! (pounces). A folder is essentially just a file; a special type of file that has as its data, pointers associated with file identifiers. Locate the file identifier in a folder (“file of file names”) and you have access to that file’s pointers which tell you where to start looking for the file's stored data.
A folder is known to be a special type of file, just as a file .DOC is assumed to be a special type of file that can be handled by MSWord, and XLS is a special type of file that can be handled by Excel, and a TXT is ....
We already have "special types of files”, no matter how we identify them.
When I execute the file diary.doc, which is not tagged as a folder-file, I expect MSWord to leap to attention.
And when I execute the folder-file Folder.DOC I expect Windows Explorer to leap to attention (and to open that folder whose file identifier is Folder.doc
We already know that Windows software can open Folder.doc (when it is the identifier of a folder-file) because explorer shows me the contents (files, mainly) of that folder Folder.doc.
There is no escape from the established fact that a folder CAN have an extent association as that part of a file-identifier that exists to the right of the rightmost period in the file’s name. The only question is “What to do with it”.

I recommend simply removing all dots from your folder names

Good recommendation. But if you were my consultant and I was your client and you came to me saying “The project cannot proceed until everyone has gotten rid of the extents to folders that have them”, I’d start looking for a new consultant!

Sincerely: Best Wishes
Chris

[void]

But why restrict the results to files-only by default? (more below)

ext:txt shouldn't match a folder ending with .txt
It should only return txt files that will open in Notepad.

Everything treats folders as having no extension.
The extension property always returns a blank/empty string for folders, even when the folder contains a dot (.)

The Windows registry works in a similar way, folders ending with .txt aren't associated with text files, they don't open with notepad, they are treated as a folder.

Thanks Void, this works as a method for locating FOLDERS with extents of "DOC", but still the question remains, how can I locate OBJECTS (which you define as Files and Folders) with extents of "DOC"?

Please try the following search:
*.doc

Want to start a debate? Should the file "image.tar.gz" show "tar.gz" under the Extension column? (hint: it only shows "gz")

Everything would have to be aware of common extensions containing dot (.)
Otherwise, Everything-1.5.0.1344a.x64-Setup.exe would have the extension 5.0.1344a.x64-Setup.exe

@VOID parts of this topic should, perhaps, be hived off to a separate topic in the General or Suggestions forum?

This is all on topic to me.
Please feel free to make a new topic if you want.

[froggie]

This is clear to be now, but wasn't obvious before I read this topic. Perhaps a note in .ext documentation would be useful.

[ChrisGreaves]

ext: will match files only. Please try the following search:

*.doc folder:

Hello Void. I agree that ext: matches files only. And yes,

*.doc folder:

works.
My contention is that Everything treats the user's use of "ext:" in a non-standard fashion to any other modifier that operates on searches for Objects.

I ought not flog this thing to death, but I want to go on record pointing out this apparent anomaly.
I know now about "ext:" being a macro for "files:ext:", but until I know this, I have used the Search Box as an explicit description of my requirements

Microsoft

any object that contains the string "Microsoft" anywhere in its name.

xls

any object that contains the string "Microsoft" anywhere in its name.
and so on and so on for hundreds of examples

ext:xls

any object that contains the string "xls" anywhere in its extension.
Suddenly the modifier "ext:" automatically includes an extra unstated modifier

files:

To the best of my knowledge, ext: is the only SEARCH modifier with this hidden agenda.

The user already has access to the modifiers

files:

and

folders:

The user already has access to macros, although I have not tried to implement the specific macro.

Why not maintain the excellent versatility of Everything by allowing the user to build their own search string?

To put it another way, would the world come to an end if ext: no longer included the hidden agenda?

I still have insufficient knowledge of Everything at this time, but I do know that i was greatly surprised when

ext:doc

did not produce my "folder.doc" as an Object in the Result List. That was unexpected!

I think that is is an issue, but a peripheral issue. Perhaps we could defer further discussion until Everything 1.6 comes over the horizon?

Cheers, Chris

[ChrisGreaves]

Why shouldn't Folders be treated as having a file extension you ask? Because software cannot open a folder as a "document". Windows doesn't try to determine "should this folder be opened up by Microsoft Excel or Word Perfect when double-clicked?"

Hi Raccoon, I am behind in my replies.

(1) There is no doubt that Windows allows me to create specifically "Folder.doc"
(2) Windows Explorer allows me to double-click on the yellow folder icon; does not try to open the folder with MSWord; does open the folder and shows its contents in the right-hand pane.
(3) Everything 1344a allows me to double-click on the yellow folder icon; does not try to open the folder with MSWord; does open the folder and shows its contents in the Windows Explorer right-hand pane.

Untitled.png (37.36 KiB) Viewed 5675 times

So far: so good. Both Windows Explorer and Everything do what (self-centred!) I expect.

My issue is with Everything's "ext:" modifier, something that as far as I know does not exist in Windows Explorer.

Everything acts (seems to expand) the modifier "ext:" as a type of macro.
My experience is that "ext:" operates as if I had typed "files:ext:"

Right now my quixotic stance is that this expansion (to files:ext:) is a hidden design feature.
In particular, given that Everything returns a set of Objects in the Result Pane - unless explicitly restricted by files: or "folders:" - and clearly my files with an extension of "doc" and my folders with an extension of "doc" are Objects, they should be returned as Objects in the Result Pane when I specify only "ext:doc" in the Search Box.

I confess now to feeling a bit woozy and incoherent about this. I know only that as a novice user I was greatly surprised when after six months of building search strings, my string "ext:doc" did not return my folders as objects in the Result List.

For the record, both Windows and Explorer execute a folder.doc correctly. The issue is not with how Everything executes folder.doc, but whether or not Everything decides to show folder.doc in the result List.

Cheers, Chris

[ChrisGreaves]

This is clear to be now, but wasn't obvious before I read this topic. Perhaps a note in .ext documentation would be useful.

Hi Froggie.
I shall document it!
If only in "Traps For Young Players.doc"
Cheers, Chris

[NotNull]

My issue is with Everything's "ext:" modifier, something that as far as I know does not exist in Windows Explorer.
[...]
Everything acts (seems to expand) the modifier "ext:" as a type of macro.
My experience is that "ext:" operates as if I had typed "files:ext:"

Explorer on Windows 11:
(I guess Windows calls it FILE extension for a reason

2023-05-08 19_44_58-T__extensions.png (41.99 KiB) Viewed 5658 times

BTW Everything:

2023-05-08 19_52_36-t__ex - Everything (1.5a) 1.5.0.1344a (x64).png (22.78 KiB) Viewed 5658 times

ext: is a function that works on files only in Everything.
Adding search modifier files: to that is redundant (if that is the right word?)



For the fun of it, press 'F2' on a file and the extension is not highlighted/selected
press 'F2' on a "folder with extension" and the extension is also highlighted/selected.

(not that I care much which way "folder extensions" behave, as long as its behaviour is consistent)

[void]

Why not maintain the excellent versatility of Everything by allowing the user to build their own search string?

To put it another way, would the world come to an end if ext: no longer included the hidden agenda?

In Everything, only files have an extension.
This is unlikely to change.



In Everything, folders have a (null) extension.

A (null) extension is different to no extension (or an empty extension)

ext: without a parameter will only match files with an empty extension.
ext: without a parameter will not match folders, which you might expect.

Try not to think of ext: as only searching files.
Instead, there's currently no way to match the (null) extension with ext:



Side note, I have noticed a few issues with ext:

ext:*pg doesn't match .jpg or .mpg files. (only a leading *. should be stripped, instead the leading * is being ignored)
ext:* doesn't match all file extensions. (the single * is incorrectly optimized away -

!ext:*

will match a (null) extension)

These will be fixed in the next alpha update.

[void]

Everything 1.5.0.1346a fixes an issue with ext:*pg and ext:*

[ChrisGreaves]

Hi Void. I am ready to yield on this discussion. I still think that I am correct (grin!), but I want to get on with my current projects in Everything.
This post is rather like a defiant last-stand for the record (another grin!)

In Everything, only files have an extension.

But an overall idea is that Everything should stick to a Windows standard as much as possible, and Windows allows folders to have extensions, to wit: one or more characters to the right of the rightmost period in the file’s identifier or any path element within that file’s identifier. Thus T:\Greaves\Folder.doc\MyFile.txt

A (null) extension is different to no extension (or an empty extension)

I suspect that this refers to a field in the Folders database. I see this as a limitation as folders can, quite clearly, have what end-users think of as “an extension”.

Try not to think of ext: as only searching files.

But I don’t. I think of Objects, especially as I begin to use Search Functions and especially Search Modifiers.
A signal of this is that two modifiers

Folder:

and

File:

exist specifically to limit the work of all the other functions and modifiers to only folders, or only files. That is, the default mode of operation in Everything is, to the end-user, based on a collection of Objects where Object defined as “Files and/or Folders”.
I think that this is my main point of contention: that the ext: modifier blows this mode out of the water.

Anyway, I suspect that we have to agree to disagree, and that’s alright with me. Everything is what it is, and I have set myself the task of learning Everything as-it-is rather than jumping onto the design team. Too, my learning vehicle is “Writing a User Tutorial” and I want to get back to that.
You know, with respect and the very best of wishes.
Cheers, Chris