Windows libraries as a paper folder! (for Win 7+)

[bdeshi]

I was almost going to ask how to show the libraries with that...

[highend]

Pushed v1.0.1

Changelog + download link in the first post.
Please update and report any bugs / inconsistencies / ...

[Filehero]

Hi Highend,

Pushed v1.0.1 ...Please update and report any bugs / inconsistencies / ...

looking good, everything seems to be fine now with 1.0.1.

So, congrats to your first C# implementation .


Cheers,
Filehero

[highend]

So, congrats to your first C# implementation .

Gracias

Pushed v1.0.2

Code: Select all

v1.0.2
 • Added: - Version check (<xypaper> variable required)
 • Changed: - Better regexmatch for $libBaseFileNames

I have nothing on my list to improve it any further now...

[klownboy]

Hey highend, with the newest version 1.02, only one library appears in the library folder, the old "1920x1080" wallpaper library. By the way, that's how it appears as written "1920x1080". The other standard ones like Documents and Music do not whereas they did display on version v1.00. I don't remember if I got a chance to try v1.01. Strange because $dblib contains...

Code: Select all

1920x1080 Wallpaper|2014.05.15.11.48.14|G:\Wallpaper\1920x1080
Documents|2014.05.15.11.48.18|
Music|2014.05.15.11.48.18|
Pictures|2014.05.15.11.48.18|
Videos|2014.05.15.11.48.18|

Thanks,
Ken

[highend]

Hi Ken,

strange. I didn't change anything in GetLibraryPaths.exe...

What happens if you unset $libDB and then run it again?

[klownboy]

Yes, it is strange. I meant to say last post that I did delete $DBlib and try again but got the same result...the one library. I did it again a few times with the same result. I stepped through it to see if I could determine what was or wasn't happening. Possibly the problem comes in getting the locations or folders for the libraries. I copied a the $libList variable as it was established.

Code: Select all

$libList=G:\Wallpaper\1920x1080

Yes, there were 7 or 8 linefeeds (paragraph symbols) after G:\Wallpaper\1920x1080. Later the $libList variable had only "G:\Wallpaper\1920x1080" without any paragraph symbols after it...if that helps.
Thanks, Ken

[highend]

The content of $libList is:

Code: Select all

$libList=G:\Wallpaper\1920x1080
<linefeeds>

The name of the variable shouldn't be there...

I've wrote you an e-mail, let's handle it from there until we find what's wrong.

[Enternal]

None of the version 1.0 worked for me too but my problem is a bit different from Ken. After many tests and backtracking, it seems to be some odd issue I had with GetLibraryPaths. To test the command app that you wrote in C#, I used:

GetLibraryPaths.exe C:\Users\User\AppData\Roaming\Microsoft\Windows\Libraries\Documents.library-ms

and the results were:

Code: Select all

[Documents]
\\CRIMSONROSE\User\Document
C:\Users\Public\Documents

Looking at my libraries, they all pointed to a local source so I don't understand why the output was pointing to my computer as a network item.

The only one that worked properly for me was the music folder. Here are the results for the others:

Code: Select all

[Music]
C:\Users\User\Music
C:\Users\Public\Music

[Pictures]
\\CRIMSONROSE\User\Pictures
C:\Users\Public\Pictures

[Videos]
C:\Users\Public\Videos

$libDB:

Code: Select all

Documents|2014.05.17.20.53.06|C:\Users\Public\Documents
Music|2014.05.17.20.53.06|C:\Users\User\Music?C:\Users\Public\Music
Pictures|2014.05.17.20.53.06|C:\Users\Public\Pictures
Videos|2014.05.17.20.53.06|C:\Users\Public\Videos

The result is, Music was the only item in the library paper (obviously with the option to ignore Public locations).

Also do note that I do have the folder User shared onto the network. (I know, I know, it's a security issue to be sharing such a folder but I have other precautions set in place).

[highend]

@Enternal

No, this behavior is not related to GetLibraryPaths. It just resolves GUIDs and reports what it finds in the <url> tag.
Ok, it doesn't report back folders that do not exist (and imho it makes sense to filter them out) but network paths
that do exist are reported.

The output of your command:

Code: Select all

GetLibraryPaths.exe C:\Users\User\AppData\Roaming\Microsoft\Windows\Libraries\Documents.library-ms

Is absolutely correct. Open that file with a text editor and you'll see that it contains two url tags:
One with a GUID, probably "<url>{ED4824AF-DCE4-45A8-81E2-FC7965083634}</url>"
and the other one with:
"<url>\\CRIMSONROSE\User\Document</url>"

All v1.0.0 up to v1.0.2 had a regex bug that didn't find the network paths
and a logic error for displaying public folders

I've debugged them on Ken's computers because he had similar problems (his libraries contain network paths as well).

I'm checking if everything is working fine by creating a few more libraries with those paths but atm everything looks good.

I'll push v1.0.3 later today which should fix these errors.

[klownboy]

I've debugged them on Ken's computers because he had similar problems (his libraries contain network paths as well).

Hi highend, I checked my other desktop with Windows 8.1, it also has the same network type paths for the libraries so it must be a standard installation. I say that because I built both of these desktops, new everything, clean drives and installed store purchased copies of windows on them and I haven't altered the original libraries on either desktop. So it doesn't appear that the network type path is unusual or atypical.
Ken

[highend]

Hi Ken,

so it must be a standard installation

Nope, sorry. I've checked all default libraries (virtual machines, original installations, absolutely zero settings changed) for
Win 8 and Win 8.1 (and Server 2012 R2).

All four (Documents, Music, Pictures and Videos) use GUIDs to point to their folders.
E.g. "<url>knownfolder:{33E28130-4E1E-4676-835A-98395C3BC3BB}</url>"

What you and Enternal have in common: You both shared your user folder. Maybe that has something to do with the network paths in those library urls?

Ok, v1.0.3 is out.

Changelog & download in the first post.

I've added a mechanism to GetLibraryPaths.exe that resolves unc paths (\\netbiosname\share) to real folders. Only if they point to a folder on the local pc! Other variations make no sense because paper folders wouldn't show them anyway.

So please test the new version and as always: report any bugs

Regards,
Highend

[klownboy]

Version 1.03 worked like a charm highend and I even have the proper "Windows" icons displayed. I didn't for the "Pictures" library initially, but that was only because I had a customized file icon for Pic* and Photo*, but I got around that by having that CFI apply to drives D: through G: only.

OK I understand what you're saying about the url listing for my libraries instead of pointing to the folder. At some point I had shared files though I was initially thinking it was only the public folder but I may have shared others but only "specific" folders on each computer. I know I didn't specify a library itself. So it sounds like as soon as you share anything on a local network Windows make those changes to enable the other computers to "see".
Thanks again,
Ken
Edit: Ran it also on my laptop and it worked there as well after deleting the existing $libDB.

[Filehero]

Hi Highend,

v1.0.3 is broken - erm, still perfectly working over here.

Cascadable paper folders would help a lot with "re-building" the original Win Library structures, Don.


Cheers,
Filehero

[Enternal]

Thank you highend! It works perfectly now! Awesome!