Folder query

[Paul]

I consider "Libraries" & the name of each "library" to be shortcuts but
the files/folders that reside within each library are not shortcuts. If
you check the file path of any folder/file within a particular library,
you'll find that it's the path where the file is actually stored. While
you may be working from a Library, you are working with the exact same
file that is stored elsewhere on your computer. Modify it or delete it
from the library & you do the same at its original store. (If it were a
shortcut, the file in the original store wouldn't be effected.)

People who considers the files in the libraries as shortcuts are the
ones who will delete files and then wonder why they can't find them in
their original store (or delete them from the original store & wonder
why they're no longer in the library). Once you understand the concept
of Libraries & set them up to benefit you, they can be a great time
saver. If you don't want to go to the trouble, you're probably better
off staying out of the Library!

I prefer articles on the mechanics, in the hope they provide the level
of detail needed, without me having to do innumerable experiments.

"Inside Windows 7 Introducing Libraries"
http://msdn.microsoft.com/en-us/magazine/dd861346.aspx

I found another article, that attempted to explain the do's and dont's
from a presumably "user level", and the tech writer preparing the article,
didn't even think through all the possible things you can do, and their
outcomes. And with crappy articles like that, then I'm left to wonder
how it really works. The above article just scratches the surface.

Based on the above description, only the top level folders in a library
should have the anomalous properties, as they're actually pointers to
folders, and stored in a .library-ms XML file. The library is a virtual folder.
Things below that level (folder within folder), aren't defined by anything
on that web page. Which means, they could have regular file system properties,
or some other behavior, and we couldn't be sure without doing more
experiments.

Paul

 

[Char Jackson]

I prefer articles on the mechanics, in the hope they provide the level
of detail needed, without me having to do innumerable experiments.

"Inside Windows 7 Introducing Libraries"
http://msdn.microsoft.com/en-us/magazine/dd861346.aspx

I found another article, that attempted to explain the do's and dont's
from a presumably "user level", and the tech writer preparing the article,
didn't even think through all the possible things you can do, and their
outcomes. And with crappy articles like that, then I'm left to wonder
how it really works. The above article just scratches the surface.

Based on the above description, only the top level folders in a library
should have the anomalous properties, as they're actually pointers to
folders, and stored in a .library-ms XML file. The library is a virtual folder.
Things below that level (folder within folder), aren't defined by anything
on that web page. Which means, they could have regular file system properties,
or some other behavior, and we couldn't be sure without doing more
experiments.

I'm long past the point where I care about the mechanics of things
like this. I just want to know how it works (at the behavior level,
not the mechanics level) and how to use it. At that point I can decide
if it's even something I'm interested in. In this case, I think
Libraries work just fine, so I hope MS doesn't randomly "rearrange the
deck chairs", but if they do, I'm sure I'll adapt.

 

[Paul]

I'm long past the point where I care about the mechanics of things
like this. I just want to know how it works (at the behavior level,
not the mechanics level) and how to use it. At that point I can decide
if it's even something I'm interested in. In this case, I think
Libraries work just fine, so I hope MS doesn't randomly "rearrange the
deck chairs", but if they do, I'm sure I'll adapt.

I work a different way. I want to explain to people, why things work
the way they do as a result of "side effects". The behavior of libraries
doesn't fit some "glorious model". It's a virtual folder, with a
"come what may" model of data handling within. It's like a coat of
paint, on a dilapidated building.

I want to be able to explain to people, that perhaps the top level
of the library has a virtual behavior, while if you burrow further
down, you're back to "normal" file system behavior.

The designers of "library", could have made the whole thing
virtual if they wanted. I wouldn't know, because the "Evangelist"
chosen to write the articles at Microsoft, couldn't be bothered
to explain it. All I can say is, if Mark Russinovich had written
the article on Libraries and how they worked, we'd know by now, and
without resorting to experiments and "I think I got it..." as
an answer. Knowing the mechanics, are important to reviewing
the results, and seeing if "behavior" matches "mechanics". And also,
for detecting anomalies, such as what happened to Mick's "Temporary Burn"
folder (or finding a "Temporary Burn" folder on the DVD you just made).
Knowing the mechanics, and fitting the patterns to symptoms, is all part
of debugging things.

Paul

 

[Char Jackson]

I work a different way. I want to explain to people, why things work
the way they do as a result of "side effects". The behavior of libraries
doesn't fit some "glorious model". It's a virtual folder, with a
"come what may" model of data handling within. It's like a coat of
paint, on a dilapidated building.

I want to be able to explain to people, that perhaps the top level
of the library has a virtual behavior, while if you burrow further
down, you're back to "normal" file system behavior.

The designers of "library", could have made the whole thing
virtual if they wanted. I wouldn't know, because the "Evangelist"
chosen to write the articles at Microsoft, couldn't be bothered
to explain it. All I can say is, if Mark Russinovich had written
the article on Libraries and how they worked, we'd know by now, and
without resorting to experiments and "I think I got it..." as
an answer. Knowing the mechanics, are important to reviewing
the results, and seeing if "behavior" matches "mechanics". And also,
for detecting anomalies, such as what happened to Mick's "Temporary Burn"
folder (or finding a "Temporary Burn" folder on the DVD you just made).
Knowing the mechanics, and fitting the patterns to symptoms, is all part
of debugging things.

I understand the way you work because I used to do the same thing and
be the same way. I don't need to do that anymore, which is a huge
luxury. These days, I can just use features without needing to know
the underlying mechanics. It's like coming up out of the coal mine for
a breath of fresh air.

The computing world needs people who do what you do (and what I used
to do), but I'm very happy to no longer be one of them.