I have been using a Unix shell to download raw reads using sratoolkit/2.8.2-1. The SRA files are from the NCBI database e.g. for "https://www.ncbi.nlm.nih.gov/sra?term=SRX1157907". When I use the prefetch command (e.g. prefetch SRR2172947) consistently get the error of "path not found while resolving tree within virtual file system module - 'SRR2172948' cannot be found." I can download other SRA files like SRR12626663 without a problem, but the mentioned link has some problem.
Would it be possible to please guide me on how to solve this problem?
Human genomics data in NCBI's SRA is often under controlled access through the dbGaP system. One must request access to these files and follow special protocols to download such data. For example, researchers must demonstrate valid research needs to gain access approval and agree to follow protocols to ensure the data is securely stored.
I utilize the Apache VFS library to access files on a remote server. Some files are symbolic links and when we get the file size of these files, it comes back as 80 bytes. I need to get the actual file size. Any ideas on how to accomplish this?
Using commons-vfs2 version 2.1.
OS is Linux/Unix.
You did not say which protocol/provider you are using. However it most likely also does not matter: none of them implement symlink chasing as far as I know (besides local). You only get the size reported by the server for the actual directory entry.
VFS is a rather high level abstraction, if you want to commandeer a protocol client more specially, using commons-net or httpclient or whatever protocol you want to use gives you much more options.
I want to move Apache ACE repository & settings data (e.g. registered agent, deployment details) to another instance of Apache ACE.
I tried copyping data folders from all the bundle folders from source instance to paste in destination instance and this approach worked as well. But, I find this approach a little error prone.
I was wondering if there is some elegant way to do that.
Unfortunately, there's no direct support for this out of the box. Copying the data folders is the only way currently (as you already found out). Although you can use the (internal) APIs of ACE to access this information and write an exporter yourself...
I have a Windows application in .Net 2.0 that uses several levels of configuration files. For reasons out of my control, the application consists of a Windows app (.exe) project and several DLLs, each of which has its own app.config file.
I have successfully figured out how to read the config file for each DLL, using (in C#)
ConfigurationManager.OpenMappedExeConfiguration("my DLL's config file path", ConfigurationUserLevel.None);
This works just fine - I can confirm that I get a Configuration object from this method when pointed to the file path name of my DLL's configuration file ("foo.dll.config"). However, when I try to access a custom configuration section, I get an exception saying that the data type for my custom configuration section cannot be found.
What else do I need to do to get the typing information available to my code when loading a configuration file in this manner?
It's unfortunate but true: the way to handle this is to copy the configuration from the .dll.config files into the applications' config file. The only exception has something to do with the Settings system used in Windows Forms. I think that does the OpenMappedConfiguration for you, but I'm not sure.
I've never known why they didn't unify this in .NET 2.0 and solve the problem. Maybe I should ask.
Earlier in the day, I asked a question like this as relates to WCF, in the Oslo Forum on MSDN (http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/c93ee7f3-4f9b-4044-b1f0-43ad72fb508d). As I was searching for a blog post or some other answer (as I said above, "maybe I should ask"), the answer to my Forum post arrived.
Long story short, and somewhat tongue-in-cheek, the answer is: they didn't fix this in .NET 2.0 because they were waiting for Oslo to solve the problem.
Without trying to avoid downvotes by making sense out of that, I'll just mention: Oslo will encourage models of applications and application components to be stored in a central repository. That will include models of per-instance configuration. The theory is that all such data would be stored in a single repository (at least per-system). So, no more question of where the configuration file is located it's all in one place. No more question of finding the assembly containing the configuration section metadata - the metadata is stored in the repository along with the configuration data.
Ask me tomorrow, and I may feel differently, but right now, I may be picking up the Oslo religion...
Where would you write an error log file, say ErrorLog.txt, in Windows? Keep in mind the path would need to be open to basic users for file write permissions.
I know the eventlog is a possible location for writing errors, but does it work for "user" level permissions?
EDIT: I am targeting Windows 2003, but I was posing the question in such a way as to have a "General Guideline" for where to write error logs.
As for the EventLog, I have had issues before in an ASP.NET application where I wanted to log to the Windows event log, but I had security issues causing me heartache. (I do not recall the issues I had, but remember having them.)
Have you considered logging the event viewer instead? If you want to write your own log, I suggest the users local app setting directory. Make a product directory under there. It's different on different version of Windows.
On Vista, you cannot put files like this under c:\program files. You will run into a lot of problems with it.
In .NET, you can find out this folder with this:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
And the Event Log is fairly simple to use too:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
Text files are great for a server application (you did say Windows 2003). You should have a separate log file for each server application, the location is really a matter of convention to agree with administrators. E.g. for ASP.NET apps I've often seen them placed on a separate disk from the application under a folder structure that mimics the virtual directory structure.
For client apps, one disadvantage of text files is that a user may start multiple copies of your application (unless you've taken specific steps to prevent this). So you have the problem of contention if multiple instances attempt to write to the same log file. For this reason I would always prefer the Windows Event Log for client apps. One caveat is that you need to be an administrator to create an event log - this can be done e.g. by the setup package.
If you do use a file, I'd suggest using the folder Environment.SpecialFolder.LocalApplicationData rather than SpecialFolder.ApplicationData as suggested by others. LocalApplicationData is on the local disk: you don't want network problems to stop you from logging when the user has a roaming profile. For a WinForms application, use Application.LocalUserAppDataPath.
In either case, I would use a configuration file to decide where to log, so that you can easily change it. E.g. if you use Log4Net or a similar framework, you can easily configure whether to log to a text file, event log, both or elsewhere (e.g. a database) without changing your app.
The standard location(s) are:
C:\Documents and Settings\All Users\Application Data\MyApp
or
C:\Documents and Settings\%Username%\Application Data\MyApp
(aka %UserProfile%\Application Data\MyApp) which would match your user level permission requirement. It also separates logs created by different users.
Using .NET runtime, these can be built as:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
followed by:
MyAppDir = IO.Path.Combine(AppDir,'MyApp')
(Which, hopefully, maps Vista profiles too).
Personally, I would suggest using the Windows event log, it's great. If you can't, then write the file to the ApplicationData directory or the ProgramData (Application Data for all users on Windows XP) directory.
The Windows event log is definitely the way to go for logging of errors. You're not limited to the "Application" log as it's possible to create a new log target (e.g. "My Application"). That may need to be done as part of setup as I'm not sure if it requires administrative privileges or not. There's a Microsoft example in C# at http://support.microsoft.com/kb/307024.
Windows 2008 also has Event Log Forwarding which can be quite handy with server applications.
I agree with Lou on this, but I prefer to set this up in a configuration file like Joe said. You can use
file value="${APPDATA}/Test/log-file.txt"
("Test" could be whatever you want, or removed entirely) in the configuration file, which causes the log file to be written to "/Documents and Settings/LoginUser/Application
Data/Test" on Windows XP and to "/Users/LoginUser/AppData/Roaming/Test on Windows Vista.
I am just adding this as I just spent way too much time figuring how to make this work on Windows Vista...
This works as-is with Windows applications. To use logging in web applications, I found Phil Haack's blog entry on this to be a great resource:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
%TEMP% is always a good location for logs I find.
Going against the grain here - it depends on what you need to do. Sometimes you need to manipulate the results, so log.txt is the way to go. It's simple, mutable, and easy to search.
Take an example from Joel. Fogbugz will send a log / dump of error messages via http to their server. You could do the same and not have to worry about the user's access rights on their drive.
I personally don't like to use the Windows Event Log where I am right now because we do not have access to the production servers, so that would mean that we would need to request access every time we wanted to look at the errors. It is not a speedy process unfortunately, so your troubleshooting is completely haulted by waiting for someone else. I also don't like that they kind of get lost within the ones from other applications. Sure you can sort, but it's just a bit of a nucance scrolling down. What you use will end up being a combination of personal preference coupled along with limitations of the enviroment you are working in. (log file, event log, or database)
Put it in the directory of the application. The users will need access to the folder to run and execute the application, and you can check write access on application startup.
The event log is a pain to use for troubleshooting, but you should still post significant errors there.
EDIT - You should look into the MS Application Blocks for logging if you are using .NET. They really make life easy.
Jeez Karma-killers. Next time I won't even offer a suggestion when the poster puts up an incomplete post.