Display folders affected by file attributes searched

[Herkules97]

I would search for keywords, but I don't really know what keywords to find any older threads about it. I tried on google "voidtools show folders that has files with attribute", voidtools "file" "folder" "attribute" and "voidtools show folders for which files in results are concerne"

On to the question which is obvious from the above, can I? I've only used assumption and the windows system itself that counts Size on Disk to find out what files and folders containing sparse files are sparse.
However, the size on disk option is terrible, as you have to first wait for it to load however much, then you have to go in and look through each folder's properties and wait for that to load and so on until you find the golden boy that is barely holding on. 100gb file but only taking 10mb on disk, poor sod.

Of course I could just sort by Path to get a clearer view, but say I want to move all those folders with sparse files into some place where I will know, not with my own memory, but with a folder.

[NotNull]

If you want to find sparse files - I am not aware of the existence of sparse folders; doesn't make sense too - you can search for

Code: Select all

attrib:P

(see https://www.voidtools.com/support/everything/searching/ for more info)


TIP: Out of the box, attributes are not indexed. So searching for them will be slow.
To speed up the process, you can index file attributes too, even if it is only temporary, when you want to search for attributes:

• Enable Index attributes (under Menu:Tools > Options > Indexes)

(enabling Fast attributes sort is not necessary)


You can get rid of the "sparsiness" by

• move the files to a filesystem that does not support sparse files, like FAT32 or exFat or:
• copy the files using Explorer++. Explorer++ does not support sparse files and will "un-sparse" them. Keep the copy and delete the original.

Note:
Windows is making a big mess of file attrributes. Explorer's file properties and the ATTRIB command don't show the correct attributes.

[NotNull]

Just tested this: behaviour changed from Win7 to Win10: copying on Windows 10 (1803) removes the sparse attribute too.
(same goes for copying using File Explorer)

2019-10-08 21_41_44-Select Command Prompt.png (18.13 KiB) Viewed 8278 times

[raccoon]

I may not understand the question correctly. For me, on Win7, Everything shows the folder size as being the non-sparse predicted size of the folder's contents if every file were completed. If I want to see the -actual- size on disk at the moment, I have to use a different program such as WizTree in order to see the physical correct sparse size. Not sure if this is different in Windows 10.

[NotNull]

@raccoon: I wasn't sure what he meant either.
Let's hope @Herkules97 isn't one of those hit-and-run people that we never hear from again ...

[Herkules97]

When you search using the sparse attribute, it only collects the files of course, I wasn't asking about sparse folder as that doesn't make sense to me.

It's not specifically about sparse files either, but this is where I encountered a want for what I am asking about.

I am talking about searching by sparse files, which you know shows files that have that flag.

BUT, what if you could search for sparse files and also any folder that the sparse files are in gets shown. (It would not show any folder above or below, unless you have files in the same folder as ooga.mkv or jump.mkv, but under a subfolder, then the subfolders would also be shown, wrote about it below.)

This way, not perfect though, it would show without having to open each folder, to copy/move, the sparse files are in.

So if I have
X:\mumba\ooga.mkv
X:\Jumba\Jump.mkv

Then the results window would also show the folders with the imaginary command, say show:inv
X:\mumba
X:\jumba

The reason I say it's not specific to sparse files, is because it can be used for other things too

If you search for ooga|jump and .mkv, you'd get those two files and again the folders would show up with show:inv

It could be that the search would be ooga|jump .mkv show:inv

I chose show:inv "Show:involved folders", to expand on what inv means.

Now this below makes it more complicated than it probably has to be, since if you CAN see involved folders, you could just sort by folder and then select the top folder or whatever, this can just be ignored because there is no need to make it even more complicated, but fun thinking about it.

It would be great if it could know that if you have multiple folders, that it only shows the folder that every file under the folder and its subfolders are in

So
X:\mumba\ooga.mkv
X:\mumba\slang\ooga15.mkv
X:\mumba\\shubadup\ooga.mkv
X:\mumba\gaa\ooga.mkv

Would still only return
X:\mumba
IF you use another command for it

Like how robocopy can copy only X level with LEV:X

But in this case it would have to know to only show the root folder for the files and subfolders under that folder.

But with only show:inv it'd ONLY show the folder the file is in, so if you want to see the folder behind mumba, in this case x:, you'd still have to open the folder and move it via Explorer or other file explorers.

The command could be
ooga .mkv show:inv:root
or
ooga .mkv show:inv:LV1

LV1 would show mumba, LV2 would show any subfolders that is affected by any file in that subfolder

so
X:\mumba\ooga.mkv
X:\mumba\slang\ooga15.mkv

Would show
X:\mumba
X:\mumba\slang

And if there is no file in mumba and mumba only has subfolders that have files in them, then mumba wouldn't be shown, only
X:\mumba\slang

With lv3, with only
X:\mumba\ooga.mkv
X:\mumba\slang\ooga15.mkv
Then no folder or file would be shown, as there is no lvl 3 in that search

Now if x: is lv1, then just add one higher number for every example.

x:\mumba would be lv2 for example.

I think robocopy does it like that, I remember using lv1 accidentally and it didn't copy anything because there was nothing to copy on that level, I don't know.

Just to give examples of what a search with this imaginary command would look like.

[Herkules97]

I may not understand the question correctly. For me, on Win7, Everything shows the folder size as being the non-sparse predicted size of the folder's contents if every file were completed. If I want to see the -actual- size on disk at the moment, I have to use a different program such as WizTree in order to see the physical correct sparse size. Not sure if this is different in Windows 10.

So wiztree does sort of what I'm asking? is it like getfoldersize in how you move around? Because I used both getfoldersize and everything since you move around differently with them. I did however quit getfoldersize eventually as I didn't feel like I needed to move around like that anymore.

If it's like getfoldersize, then it's not that useful as you'd need to go into each and every folder, spider your way around, to find the folders with incomplete files.

This is one or the only reason, I think, I quit using getfoldersize, as I got used to finding things with Everything, which I guess I wasn't at first when using both at the same time. I don't remember. I only know I don't use it these days.

[Herkules97]

Just tested this: behaviour changed from Win7 to Win10: copying on Windows 10 (1803) removes the sparse attribute too.
(same goes for copying using File Explorer)


2019-10-08 21_41_44-Select Command Prompt.png

Yeah, I tried using robocopy to copy attributes but that didn't work either.

It's a shame it doesn't at least work on the same drive. Only moving I think.

Even though moving is just copying the file and its attributes and then removing the one in the source destination once it's been moved inside the same drive, I think..

I don't have a convenient sparse file to try this with right now, but I think

Copying inside same drive : no sparse
Copying to other drives : no sparse
Moving inside same drive : sparse
Moving to other drives : no sparse

Maybe I did something wrong, I used /COPY DA, Data and Attributes..

[raccoon]

Since this is an NTFS volume, one possible solution is to create a hard link, symbolic link, junction (or whatever the proper term / option is called) instead of creating an actual copy. I believe one of the options allows changes to one to reflect in the other, and another option will split the link and create a mirror copy if changes are made. Perhaps this option preserves sparsiness?

Another option is file compression, which should properly compress all the zero-byte segments and free up drive space.

[therube]

Wikipedia: Sparse file

copy|move sparse files on NTFS with Windows


child: won't work with attrib:P, otherwise maybe you could work something with that.