I can use GetFileInformationByHandle to determine the number of hard links associated with a file. How can I enumerate the paths which make up those links?
For example, if C:\TEMP_1.BIN and C:\TEMP_2.BIN are hard links to the same content, and I determine from GetFileInformationByHandle that C:\TEMP_1.BIN has nNumberOfLinks=2, how can I discover the path for the other link? (e.g. C:\TEMP_2.BIN)
GetFileInformationByHandle:
http://msdn.microsoft.com/en-us/library/aa363788%28v=VS.85%29.aspx
I think you're looking for FindFirstFileNameW, which tells you all of the names a file has.
Related
About RELATIVE_URLS, the Pelican docs say:
…there are currently two supported methods for URL formation: relative and absolute. Relative URLs are useful when testing locally, and absolute URLs are reliable and most useful when publishing.
(http://pelican.readthedocs.org/en/3.4.0/settings.html#url-settings)
But I'm confused why absolute URLs would be better or not. In general, when I write HTML by hand I prefer to use relative URLs because I can change the domain of the website and not worry about it later.
Can somebody explain the thinking behind this setting in more detail?
I don't use the RELATIVE_URLS setting because it's document-relative. I don't want URLs containing ../.. in them, which is often what happens when that setting is used.
Moreover, relative URLs can cause issues in Atom/RSS feeds, since all links in feeds must be absolute as per the respective feed standard specifications.
Contrary to what's implied in the original question, not using the RELATIVE_URLS setting will not cause any 404s if you later decide to change the domain. There's a difference between specifying absolute URLs in your source document (which is what you seem to be talking about) and having absolute URLs generated for you at build time (which is what Pelican does).
When it comes time to link to your own content, you can either use root-relative links, or you can use the intra-site link syntax that Pelican provides.
For example, /path/to/*/file can you use SQL to read a file using a wildcard to fill in the absolute path? This is for a situation where I there is one component in the path which changes unpredictably.
I think the answer is no. But if you can look up the valid options by querying the file structure you could then loop around the results. However I would suggest that any system that employed this approach would be wide open to hackers.
Given an application path (or NSBundle to an application, etc), is there a way to easily/efficiently determine what content types that application can open?
My initial attempt was to read the application's Info.plist file and extract the content types listed under the kUTExportedTypeDeclarationsKey key. However, there are some flaws with this approach which I haven't been able to work around.
Not all applications use this key. For example, BBEdit does not, but instead lists a whole bunch of recognized file extensions.
UTIs are case-sensitive. Pages, for example, lists com.apple.iWork.Pages.pages as an exported content type, yet no Pages document actually has that type listed in its content type tree. Documents use com.apple.iwork.pages.pages, which is defined by the iWork quicklook generator (at /Library/QuickLook/iWork.qlgenerator).
In know that with some of the LaunchServices functions (LSCopyApplicationURLsForURL(), LSCopyApplicationForMIMEType(), etc), I can get the applications that can open a file (or a file type), but I'd like to do the inverse. (Perhaps I'll have to resort to parsing the output of lsregister -dump?)
Perhaps a simpler way to phrase the question would be: Given an application, what's the easiest way to find all files that it can open?
Any suggestions?
Take a look at LaunchServices and the provided LSCanRefAcceptItem() API.
It seems using the LSItemContentTypes key is the preferred method post-10.4.
Apple: Document-Based Applications
I'm looking for a utility that will help me find duplicate PDFs. The problem: I have a 1000s of PDF files. Some are duplicates. They are not easy to detect due differing files names and small differences in file size. Is there a utility/algorithm/library that can help me find the duplicates or show me files that are very similar (or degree of difference)?
Create an MD5 hash for each file and store it in a database. Identical files will then sort next to each other, or you can quickly search for a pre-existing key.
The problem is not yet solved in any way. What I do, is I use fdupes http://premium.caribe.net/~adrian2/fdupes.html to find exact duplicates.
But most of all, I use a workflow which minimizes duplicates. Every document that enters my system gets indexed with this perl-script I wrote: http://seegras.discordia.ch/Programs/fileindex which puts some name and an md5-sum of it into ~/.fileindex.md5 Now I can change metadata of the local PDF-files or whatever (and run fileindex again), and whenever I accidently download the same file again, I will stil lhave the md5-sum of the original file, and thus can detect whether it's a duplicate.
There's also exif-meta and exif-rename on http://seegras.discordia.ch/Programs/ which help with setting PDF metadata and with renaming PDF-files according to metadata; and if you're tagging all the files correctly, you will end up with duplicate filenames, indicating that they might be the same document within a different file.
If the files were created by the different tools, they could look the same but generate very different results because they are structured totally differently. I made some suggestions in a blog article at https://blog.idrsolutions.com/2010/09/comparing-2-pdf-files/
DiffPDF looks like something that might help you.
I remember that there is a UNIX utility called pdf2txt (see the package poppler-utils). You can try to extract the text from the files and make a textual diff.
I use Tomcat 6.0.20 and JDK 1.6.0.13.
How can I load libraries from sub-folders of %TOMCAT_HOME%/lib/ without taking the .jars out of sub-folders and putting them straight into %TOMCAT_HOME%/lib/?
The reason I want to do this, is because many apps are going to be sharing lots of libraries.
So, for the sakes of organization I want to store them into folders as such:
%TOMCAT_HOME%/lib/novell/*.jar
%TOMCAT_HOME%/lib/mail/*.jar
%TOMCAT_HOME%/lib/upload/*.jar
etc.
How would I go about this? And please provide an example.
Do I use setclasspath.bat, catalina.properties or something completely different?
Thanks in advance.
Define those paths in shared.loader property of /conf/catalina.properties file.
E.g.
shared.loader = ${catalina.home}/lib/novell/*.jar, ${catalina.home}/lib/mail/*.jar, ${catalina.home}/lib/upload/*.jar
[Edit] optionally you can also use the common.loader property for this. See what has your preference.