XYplorer Beta Club

I'm currently trying out XYplorer and found that it's possible to designate colors to certain kinds of attributes (e.g. compressed files). Is this somehow possible to achieve for encrypted files as well? Isn't this merely an attribute in the file system also?

I use the built-in encryption feature in NTFS a lot. In Windows Explorer, encrypted files and folders are denoted with a distinct color. This feature is essential as I can't mentally keep track of every encrypted file on my system. For some reason, most file manager replacements I've tried seem to lack this feature. Without it they can't really serve as replacements for my needs. Thus, I hope this is easy to achieve in XYplorer. I can't find any reference to encrypted files in the documentation nor on the forums.

A quick Google search produced the following:

The core Windows API is aware of the encryption attribute for a given file.

To detect whether a given file or folder is encrypted, you can still use GetFileAttributes(), as is the case with compressed files. The only difference is that now you should check attributes against a constant named FILE_ATTRIBUTES_ENCRYPTED. However, EFS gives you another chance: a new Windows 2000-specific function called FileEncryptionStatus().

A Programmer's Perspective on NTFS 2000 Part 2: Encryption, Sparseness, and Reparse Points

This attribute could simply be utilized as such:
/encrypted (or /e) -> matches all items with ENCRYPTED set

Wow. You really deserve that feature! I just built it in.

Your post is definitely setting new wishing standards: I strongly encourage that users in future add detailed coding instructions to their wishes. It will help speeding up the fulfillment process.

But it was not 100% perfect: it's FILE_ATTRIBUTE_ENCRYPTED, not FILE_ATTRIBUTES_ENCRYPTED.

Welcome to the XY fan club!

Thanks! That was fast. It's a nice product you have there. Best Explorer replacement I've tried so far. I might just have to buy it.

kimsnarf wrote:Thanks! That was fast. It's a nice product you have there. Best Explorer replacement I've tried so far. I might just have to buy it.

Oh, you must buy it! It just feels better.

And, please test that encrypted thing. I have no encrypted files over here.

The encryption color filter works very nicely! However, the selected color only appears in the file list view (right side), not in the tree view (left side). Is this behavior intentional? I couldn't get colors in the tree view for other attributes either. This would be useful to indicate attributes on folders without having to open them.

The encryption attribute also works correctly for file properties and finding files. It's a good implementation.

To anyone interested: Encrypting a file in Windows XP is as simple as right-clicking it and choosing "Encrypt". Or by going through right-click -> Properties -> Advanced. Decrypting works the same way. Just remember to decrypt the files before wiping/reinstalling the Windows XP installation, as the files can't be read without the proper certificate (tied to your user profile in XP).

The color filters are currently only implemented for the list. Wouldn't harm to do them for the tree, too, I guess...

admin wrote:The color filters are currently only implemented for the list. Wouldn't harm to do them for the tree, too, I guess...

hmm I am not in favor of this ; I'm lazy so let me quote myself

jacky wrote:I do beleive it should not be extended to the tree.
Thoose new attribute filters should behave like current color filters do, so they should be LIST filters. The tree already has its colors (box, highlight, etc) and it might get messy to add (part of) the color filters there.

Ok, it means hidden folders are only recognizable through their icons, and system ones not at all, but that's only in the tree. They would get color filtered on the list (as color filters behave now) so would be allright by me. (system folders could get some red cross/symbol as overlay maybe if really needed maybe...)

Or make it an option, "Apply color filters to the Tree" Cause I for one really dont want them here

jacky wrote:I do beleive it should not be extended to the tree.
Thoose new attribute filters should behave like current color filters do, so they should be LIST filters. The tree already has its colors (box, highlight, etc) and it might get messy to add (part of) the color filters there.

Ok, it means hidden folders are only recognizable through their icons, and system ones not at all, but that's only in the tree. They would get color filtered on the list (as color filters behave now) so would be allright by me. (system folders could get some red cross/symbol as overlay maybe if really needed maybe...)

Or make it an option, "Apply color filters to the Tree" Cause I for one really dont want them here

I don't quite understand your reasoning. Interface colors can already be specified both in the tree view and in the file list view. Why should color filters be considered harmful in one (the tree) and not in the other (the file list)? The same potential for messiness applies to both. And in both cases it's only a matter of avoiding picking colors that interfere.

The only reason extension color filters are not useful in the tree is because folders normally don't have extensions. But if pattern matching were to be utilized beyond extensions it could be useful for folders as well, e.g. to trigger on certain file/folder names.

Regardless, attribute color filters are unquestionably useful for the tree view to indicate attributes on the folders. There's thus no reason that they should be limited to the file list view simply because another type of color filter (extensions) normally only applies to files. On the contrary, this behavior is inconsistent and rather confusing since attribute colors now appear in one view and not in the other for the exact same folders.

Of course, if the color filters should affect the tree drawing speed noticeably, the feature could just be made optional with a check box. But if it doesn't, I see no reason to clutter the color filter configuration with yet another option.

If there's something I've misunderstood here, please explain it to me.

Until reading the last couple of posts, I didn't think this thread applied to me at all as I'm on W2K/FAT32...but now that I understand more about attribute colors, it may partially at some point...

Given that we are able to define custom colors (Very nice!), which allows a very wide variety, then for those few users who make use of attribute color filters, (not extension CF which are likely used most), I say it's up to them to pick colors that don't conflict and let the tree folder show in the same color as on list...

Had we been limited to the standard colors, then there might not be enough choices to pick from, but as one could put encrypted files in some odd/funky/weird color, it can stand out from the more typical basic colors that I suspect most use for other values, like red for XLS or blue for PDF.

kimsnarf wrote:I don't quite understand your reasoning. Interface colors can already be specified both in the tree view and in the file list view. Why should color filters be considered harmful in one (the tree) and not in the other (the file list)? The same potential for messiness applies to both. And in both cases it's only a matter of avoiding picking colors that interfere.

hmm not really. On the Tree you can specify Boxed Branch Colors, to change the background of an item an its subfolders. This is a great feature, and I use it a lot.
This highlighting feature is a tree-related one, and only affects the Tree.

What this means is, I can choose the text color and default background color used on the Tree, plus having a lot of Boxed branch colors aswell.
And on the List, I can have another text color, and another background color (couple of them actually, with alternative grid colors ).

Now when I set up my color filters, I set them up as List filters, as its what they are (see how the list of color filters uses the List bg color). So I make them to match with my List bg color, not my Tree bg color or the different Boxed colors I use. Hence having them working on Tree could cause some mess up on the Tree!

BTW, even though they're proly most use as extension filters, Color filters are actually NOT limited to extension, they're checked against the whole filename so can be made to match something else than the extensions (or in addition with it for that matter)

kimsnarf wrote:Regardless, attribute color filters are unquestionably useful for the tree view to indicate attributes on the folders.

Bah, opinions I have items with the System attribute set to a color, and I'm glad folders with that attribute show up with that color only on the List!

kimsnarf wrote:There's thus no reason that they should be limited to the file list view simply because another type of color filter (extensions) normally only applies to files.

Well as I said before, we're talking about Color Filters here, and they are List-related. (just like VF for example) And again, they are NOT limited to extension, and can perfectly match folder's name too.
(besides, I got quite a few folders that have "extensions", as in they have dots in their names )

kimsnarf wrote:On the contrary, this behavior is inconsistent and rather confusing since attribute colors now appear in one view and not in the other for the exact same folders.

I don't think this is inconsistent, as Color Filters are List filters. Besides, I have plenty of folders that have a different color on Tree (should it be Boxed Branch or Highlight Color) that isn't used on List, and that's fine by me and don't fall as inconsistency either, as thoose are Tree-features.


And yes, as I said, simply having an option to apply them to the tree or not could do fine.

kimsnarf wrote:To anyone interested: Encrypting a file in Windows XP is as simple as right-clicking it and choosing "Encrypt". Or by going through right-click -> Properties -> Advanced.

Not here. No such item in my menu. (XP Prof SP2)

Concerning Color Filters for the tree I'm thinking about making a per-filter switch, e.g. ">t" (meaning: "apply in tree, too"). Would not clutter anything in config and give total control to the control freaks! For example:

/s >t
/e >t
/d
*.zip;*.rar
etc. ...

admin wrote:Concerning Color Filters for the tree I'm thinking about making a per-filter switch, e.g. ">t" (meaning: "apply in tree, too"). Would not clutter anything in config and give total control to the control freaks!

Excellent idea!

admin wrote:Concerning Color Filters for the tree I'm thinking about making a per-filter switch, e.g. ">t" (meaning: "apply in tree, too"). Would not clutter anything in config and give total control to the control freaks!

I'm OK with that. I'd still prefer consistency between the tree view and the file list view, given that both display the same folders. I can't quite understand the reason for wanting to pick different colors for these two views. But for some this apparently makes sense, so your suggestion provides a nice middleground. The danger is that such a switch is hidden from the user interface, i.e. the user must be explicitly notified of its existence to be able to use it. It's thus very important to explain its use above the color filter list box.

I don't have time to consider this further now, but it seems like a good solution to me. Even though I'd prefer that the colors appear in the tree view by default, and that this behavior can instead be turned off by some switch. I think this will be less confusing to new users.

kimsnarf wrote:I'd still prefer consistency between the tree view and the file list view, given that both display the same folders. ...

There's quite a lot of "inconsistency" between the tree view and the file list view: not only colors, but e.g. Favorites are bold only in the tree, folders selected and focused in the list are not selected and focused in the tree, sort order etc. Also that the list shows files and the tree does not could be called "inconsistent" (the tree model can perfectly show files if you want it to -- jacky would like that I guess when I think of his recent "indented list" idea ).
So, instead of "inconsistency" I would rather call it different points of view which offer you different aspects resp. accentuate different properties of the phenomenon (the file system). Instead of duplicating identical information in two places it's not unclever to trade redundancy for, well, regionalization: here you find this info about X, there you find this other info about X.
Basically, the tree is WHERE, and the list is WHAT. (Whereas in a dual-pane file managers you have WHAT-WHAT, hehe ) All the tree coloring (favorites bold, highlight, boxed branch) in XY has one main purpose: ease orientation and navigation ("Where am I and where is my destination?"). All the list coloring, on the other hand, serves to ease identification ("What do I have here?").
So, while I said before that "colors in the tree won't harm", I also think that they might somehow blur the basic functionality by adding an informational overload.

OTOH, I can understand, of course, that color-coding e.g. encrypted folders not only in the list but in the tree as well can be useful. The ">t" switch will allow this.