Is there a way to download attachments from the CR/PR in Rational Change Server via Web Mode CLI?
I know that is possible to do via the classic client's ccm, but in the Web Mode CLI it isn't possible in the same manner (i.e. ccm export does not exist or there is a permissions problem).
Regards,
Pawel
EDIT:
I eventually arrived at the solution.
You can cat the contents of the object represented by its objectname, the problem was that the attachment's object name has a white space inside...
ccm query "is_attachment_of(cr('CR_PR_displayname'))" -u -f "%objectname %attachment_name %attachment_size"
then with the objectname of an attachment:
ccm cat objectname_of_an_attachment > C:\attachment_name
attachment_name - holds the name with extension
attachment_size - holds the size in Bytes
Related
I'm trying to read emails from Outlook (desktop client on macOS) installation programmatically.
For Thunderbird I only need to read the files stored in /Users/xxxx/Library/Thunderbird/Profiles/xxxx.default-release/ImapMail/someemailaccount/.
Each file on that directory is named after the name of each folder on the email account (INBOX, Sent, etc.) and it contains all the emails (header, body and attachments). So all I have to do is to read that file with some programming language and apply the right decoder depending on the Content-Transfer-Encoding header.
For Outlook I found this file: /Users/xxxx/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/Main Profile/HxStore.hxd but it looks doesn't look to be readable, is it on a binary format? it is compressed or encrypted?
I tried to see its contents using Hex Field app and it displays that the file contains some blocks of data but those blocks look to be broken or encrypted/compressed (more info about that file here https://boncaldoforensics.wordpress.com/2018/12/09/microsoft-hxstore-hxd-email-research/):
<html><head>
<meta http-equiv="Content-Type" cp="text/;ñ; charset=utf-8"></Lð<body><div dir="ltr">1234567890ñ>
...
As you can see above, the contents look to be there but there are some strange characters on it. Also, the file has a lot of sections with no characters or random ones.
Does anybody know how can I read this file?
If you use the older outlook interface (or switch back to it) you can access the underlying sqlite database pretty easily.
However this will be discontinued at some point and Outlook will completely switch to the new interface based on Core Spotlight.
I am also looking for a way to access emails from the new interface, and yes the data seems to be in this file. Anybody else have pointers on how to access?
I have a C# Outlook add-in that is using the Redemption library.
This add-in, among other things, copy the selected mail to a share somewhere on the network.
It usually works pretty well but sometimes, the .msg file on the share seems to be corrupted. It cannot be read by the service that tries to process it. Double clicking on it shows this message: "Cannot read the item".
Sometimes, I can see an error message:
SaveEmail - System.Runtime.InteropServices.COMException (0x8007000):
Error in StgCreateDocFile: 0x8007000 at
Redemption.IRDOMail.SaveAs(String Path, Object Type) at
XYZNameSpace.Email.SaveEmail(...)
Here the code that save the mail to the share:
// Save the mail in a temp local file first
mailItem.SaveAs(temppath, Outlook.OlSaveAsType.olMSG);
(... some processing ...)
// Reload the mail
RDOMail rm = rdoSession.GetMessageFromMsgFile(temppath);
// Save it again on a share
rm.SaveAs(filePathName, Outlook.OlSaveAsType.olMSG);
Note 1 : I don't know why the mail is first saved locally!
Note 2 : It is using an older version of Redemption (2015).
Note 3 : The size of the message doesn't seem important. However, they are
usually between 2 and 15 MB.
Many thanks in advance.
IStorage API does not really like remote drives - there is no way for the storage sharing features to work.
Opening and saving the message the second time really does not make much sense - why not simply copy the MSG file using the file system API?
Our application is entirely built on websockets. We don't do any HTTP request-reply. However, we are stuck with file download. If i receive file content via websockets can I wrote to local folder on user computer ?
If it makes a difference, we are only supporting Chrome so not issue if it doesn't work on other browsers.
Also, I know i can do this via HTTP. Trying to avoid it and stick to websockets since thats how the entire app is.
Thanks a lot in advance!
The solution depends on size of your file.
If size is less than about 50 MB, I would encode file's content to base64 string on the server and send this string to the client. Client should receive parts of the string, concat them to single result, and store. After receiving whole string, add link (tag <a>) to your page with attribute href set to "data:<data_type>;base64,<base64_encoded_file_content>". <data_type> is a mime type of your file, for example "text/html" or "image/png". Suggest file name by adding download attribute set to name of file (doesn't work for Chrome on OS X).
Unfortunately I have no solution for large files. Currently there is only FileEntry API that allows to write files with JS, but according to documentation it is supported only by Chrome v13+, learn more here https://developer.mozilla.org/en-US/docs/Web/API/FileEntry.
I'm creating Firefox addon that registers new protocol which should provide HTML to Firefox from file stored on disk (generated by binary exe).
I have problem with images in tags and (probably) css styles that refer to local file. They aren't load properly and I'm getting a message in the errorconsole like this :
Security Error: Content at moz-nullprincipal:{afde522e-6b29-4359-9959-c46c749687f6} may not load or link to file:///E:/xowa_app/user/anonymous/app/img/file/magnify-clip.png.
My protocol flags : nsIProtocolHandler.URI_IS_LOCAL_FILE | nsIProtocolHandler.URI_IS_LOCAL_RESOURCE | nsIProtocolHandler.URI_STD | nsIProtocolHandler.URI_INHERITS_SECURITY_CONTEXT. (I don't know whether I understand properly MDN reference)
nsIProtocolHandler interface specs need to me that I implement function to creating new channel (MDN) when it is opening URI by the protocol. I create a channel from URI located on disk (html generated by program). The channel has owner property that "grant or deny privileges" and I setted even the owner to system principal who "passes all security checks" (MDN) but the errors are the same.
It seems to that just removing URI_INHERITS_SECURITY_CONTEXT flag (and leaving change owner to system principal) resolves my problem although I don't know when there is need to use this flag.
I'm having some real issues in getting local files to open up via a browser using a custom protocol. Now before you shoot me for the custom protocol, this web app will be working in a closed intranet environment, so I have full control to add these protocols for all users. The app works fine at the moment, but I've been requested to bypass the Open / Save dialog for files as it's 'annoying' and 'time consuming' (yeah, I know...I tried to tell them), so here I am in uncharted territory!
Here's an example then of what's not working (I'm using Notepad in this example to test it in Server 2008 R2 with IIS7):
Using the info on Registering an Application to a URL Protocol I've added the following to the registry:
HKEY_CLASSES_ROOT
opentxt
(Default) = "URL:opentxt Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "C:\Windows\System32\notepad.exe,1"
shell
open
command
(Default) = "C:\Windows\System32\notepad.exe" "%1"
So now, in theory, it should be as easy as having the following link in my html
Open File
And it does almost work - click on the link and it opens up Notepad instantly, however I'm presented with this error in notepad.
The filename, directory name, or volume label syntax is incorrect
The file definitely exists in that location (I can read it using http: //localhost/openme.txt), and I've tried to represent the link in as many different formats, such as described here but just can't get it to work.
Any ideas where I'm going wrong?
Quite simply, you're confusing your two different protocols.
Your protocol - and the Url that you pass to notepad - is opentxt://localhost/openme.txt. The working location of the file is http: //localhost/openme.txt. These two are not the same!
HTTP is a protocol that is natively understood by the operating system and, as such, Notepad can pass the HTTP Url to the operating system, which will in turn connect to localhost using port 80 and send a request for that resource. The file is returned, and Notepad has its data. This is all handled within operating system libraries that define the behaviour of HTTP.
Your opentxt protocol doesn't have this support unless you code it. Notepad doesn't know what to do with it - so you see your error message.
A way to handle this easily is to create your own application that handles the protocol. If you had an opentxtHandler.exe wired up through the registry, it would be passed the opentxt:// url, and can then process it appropriately. This might simply mean changing the protocol from opentxt to http and then passing it to Notepad - or it could be something more complex.