Just run the command:
get-childitem rootdir -include *.extension -recurse | foreach ($_) {remove-item $_.fullname}And that is it. Thanks Scripting Guy.
This is specially useful for me because very often, after I make changes in project reference in VS.NET some .dll files are left “out of sync” and and make parts your project act as if you did not re-compiled them. Sadly there is no easy way to tell VS.NET to get rid of all the .dll files that may be causing problems.
Make that PDF secure! That is one of the funniest requests I have received from a boss at one of my jobs… I answered by asking: “Secure? How secure?” and my boss told me: well, I want the user to be unable to modify it, copy it or print it.
Why do I say that this request is funny? Well, because this was a web application, the typical HTML+JavaScript+JSON/XML+Choose-the-Server-Side-Tech-You-Like application. Now, of course you can not really “display” a PDF with that technology, you need to have a PDF viewer like Acrobat Reader so that your user can “see” the PDF, and, of course, all the indented users for this intranet web applications had it installed.
My boss had read that Acrobat had an option to make a PDF read-only with a password, and that it was even possible to “protect” the document so that it could not be printed… sounds like the solution… no? well, first of all , if you can see it, it means that the structure of the document is available to the reader, which means that the document is not really encrypted, and that means the any tool capable of reading and writing .pdf will be able to remove the password without even worrying about trying to guess it using a brute force (or even an heuristic) attack.
What can you do then? Well you can actually encrypt it… that will prevent the user from modifying it… but it will also prevent it from being seen… unless the user has the password… which also means he/she can un-encrypt the document and remove the protection.
There is no thing that can be done then? well, if security of this document is actually a priority, you could create a custom reader unable to print… that should work should it? Well, not exactly, the user can always just press the “printscreen” key that is available in all keyboards and get a copy of the document… I have read that it is possible to install some DRM level protections in some OSes that could detect that, but when you take it to that level, a new questions is brought in to the table: is it worth the cost? does the document actually needs that kind of security? if not, it means this is a case of toy security, your boss just wants this feature because it sounds like a feature that “would impress the user” but not something that is really required by the application, he/she has not really give this features (and its implications) some thought.
Lets say that at my boss says: “Yes, that level of security is really needed” (very unlikely, but could happen), well, that brings in the next question: what if the user just goes, takes one of then great modern digital cameras, and takes the picture from the screen monitor? (and then spends a few days retouching it in the Gimp or Photoshop).That means it will be able to steal the information, and even be able to print it. How can you prevent that from happening? How can you make a document that is actually secure even after that?
Well, the answer is that if what you want to prevent is the theft of information, the only way is to not allow the user to see the document, if the user can see it, the user can copy it, one way of another (there is even the possibility that the user has photographic memory) and there is no way you can make the user “forget” that he saw the document.
But lets say that what you want to do is detect if a document is a forgery that is, right at the moment that you see it printed on a paper, you want to be able to know if it came from your system (and it was altered by someone after it was copied or not)… the only way to do that, is embedding the same information that the document has in a 2D barcode (including something that uniquely identifies the document), and also embed in another barcode a digital signature that is able to validate the data. That is the only way I know you can demonstrate that the document is a forgery… obviously, by the time you have explained this to you boss (if he/she has managed to make sense from it) the most likely thing is that he/she is unwilling to ask you to do all that it is needed to achieve this goal, mostly because it is nothing like what he/she wanted in the first place: it something much more abstract, and requires a barcode reader to verify the document.
A while ago a wrote a small post to remind me of How to find files containing a string in Unix.
Now, I have learned how to do pretty much the same thing but with Powershell:
get-childitem {directory} –include {file pattern} -recurse | select-string -pattern "{string to Find}" -casesensitiveYou can write a path in {directory} or nothing to use the current directory.
GET -> Read
DELETE -> Delete
POST->Insert/Update
PUT ->Insert/Update
Yes, I mapped both POST and PUT map to the same CRUD operation, but now I am not that sure this mapping is completely right…
I have learned that the difference between POST and PUT is the URI, in PUT the URI identifies the entity enclosed with the request (the entity you wan to Insert or Update), while in POST the URI identifies the resource that will handle the enclosed entity.
So, POST is like saying "Resource X, do something with this Entity", while PUT is more like "Insert/Update this Entity as Resource X"
So POST is more like “Tell ‘X’ to do something with ‘E’” and that has really no direct mapping with a CRUD operation… of course, a POST, internally, can do one, or many of the CRUD operations using the data of the entity that is being passed to it as a parameter… Does that mean that POST maps to all CRUD operations?
I guess I need to learn more about this…