When I enter the incorrect password for an encrypted file Vim displays gibberish.
If I accidentally save this file (:wq is muscle memory) I will lose the original content. How do I prevent the save of incorrectly decrypted files? Is it possible to set the 'readonly' option when the file is decrypted incorrectly?
Additional question - Is it possible to recover the original content of the file after we have saved the incorrectly decrypted file?
PS - I was using :se cm=blowfish2
How do I prevent the save of incorrectly decrypted files?
Adding the following map to .vimrc prevents mistakenly overwriting an encrypted file by asking the user if he/she really wants to quit:
au BufWinEnter * if &key!="" | cnoremap wq if input("Sure of quitting encrypted file? (yes or no)") == "yes"\|wq\|endif|endif
The important part here is the &key!="" comparison which evaluates to TRUE only if the file is encrypted.
Is it possible to set the 'readonly' option when the file is decrypted incorrectly?
An incorrectly decrypted file will often display unusual characters. This can help to detect whether a file is incorrectly decrypted, like so if search("[¶Éâ½]")!=0 | set readonly | endif. This comparison evaluates to TRUE if any of the characters inside "[]" appear on the file.
Is it possible to recover the original content of the file after we have saved the incorrectly decrypted file?
From :help encrypt
WARNING: If you make a typo when entering the key and then write the file and exit, the text will be lost!
Related
how can I enter a 2KB formatted TXT (line breaks) that should get URL-Encoded? Just pasting it into the input line doesn't work as the result is not formatted in any way.
https://www.dropbox.com/s/z934uvy6bjz98e3/Screenshot%202016-04-13%2014.28.16.PNG?dl=0
If you have a really complex text, I recommend you to just keep the text in a plain text file somewhere in your disk, and use a File Dynamic Value to reference it, and wrap the whole thing in your URL-Encode Dynamic Value.
Some steps:
Create a file with your content
In your URL-Encode dynamic value, right-click on the Input field and pick File > File Content
Click on the newly created File (Not specified) token, and you'll be prompted to either pick or drag-and-drop a file
You should be good to go. And whenever the file changes, you can send the request, and it should be up-to-date, it's just a pointer to the file.
If you use proper URL encoding, the linebreaks \n should be encoded as %0A. This
foo
bar
baz
will be encoded as
foo%0Abar%0Abaz%0A
When I call sqlite3_open_v2() on a zero byte file with flag SQLITE_OPEN_READWRITE, the function returns zero. Then the "PRAGMA quick_check;" statement returns a row containing string "ok". So zero-byte file is considered a valid database? Seems a little counter-intuitive?
Well I don't think it's "valid". If it's zero bytes, it's nothing, other than a reference. Yes you can open it. But that's not working if the file has >= 1 byte.
So as long as the file is 0 bytes, you can open it; once you start making changes, it will become an SQLite file.
If you open a non-SQLite file and try to make changes, it will give you an error message:
Error: file is encrypted or is not a database
The (only) way to create a new, empty database is to attempt to open a non-existing file.
A zero-sized file is considered the same; it's just an empty database.
There are some settings (such as the page size) that must be set inside an opened database connection, but that would affect the structure of the database file.
Therefore, SQLite delays actually writing the database structure until it is actually needed.
Is there a way that I can always append new text into the beginning of a text file in Qt? i'm using QFile::Append to do it.
file.open(QFile::Append | QFile::Text)
You can't, see the documentation at http://doc.qt.io/qt-5/qiodevice.html:
QIODevice::Append 0x0004 The device is opened in append mode, so that all data is written to the end of the file.
The problem is even worse, a file is usually stored sequentially on disk, appending (better: inserting) at the start of a file would involve moving all data towards the end of the file, thus a reorganization of filesystem blocks. I'm not sure such a filesystem exists, but if, I guess it would only allow insertion of a multiple of the filesystem block size into a file.
I am using file upload mechanism to upload file for an employee and converting it into byte[] and passing it to varBinary(Max) to store into database.
Now I what I have to do is, if any file is already uploaded for employee, simply read it from table and show file name. I have only one column to store a file and which is of type VarBinary.
Is it possible to get all file information from VarBinary field?
Any other way around, please let me know.
If you're not storing the filename, you can't retrieve it.
(Unless the file itself contains its filename in which case you'd need to parse the blob's contents.)
If the name of the file (and any other data about the file that's not part of the file's byte data) needs to be used later, then you need to save that data as well. I'd recommend adding a column for the file name, perhaps one for its type (mime type or something like that for properly sending it back to the client's browser, etc.) and maybe even one for size so you don't have to calculate that on the fly for each file (useful when displaying a grid of files and not wanting to touch the large blob field in the query that populates the grid).
Try to stay away from using the file name for system-internal identity purposes. It's fine for allowing the users to search for a file by name, select it, etc. But when actually making the request to the server to display the file it's better to use a simple integer primary key from the table to actually identify it. (On a side note, it's probably a good idea to put a unique constraint on the file name column.)
If you also need help displaying the file to the user, you'll probably want to take the approach that's tried and true for displaying images from a database. Basically it involves having a resource (generally an .aspx page, but could just as well be an HttpHandler instead) which accepts the file ID as a query string parameter and outputs the file.
This resource would have no UI (remove everything from the .aspx except the Page directive) and would manually manipulate the response headers (this is where you'd set the content type from the file's type), write the byte stream to the client, and end the response. From the client's perspective, something like ~/MyContent/MyFile.aspx?fileID=123 would be the file. (You can suggest a file name to the browser for saving purposes in the response headers, which you'd probably want to do with the file's stored name.)
There's no shortage of quick tutorials (some several years old, it's been around for a while) on how to do this with images. Just remember that there's essentially no difference from the server's perspective if it's an image or any other kind of file. All the server needs to do is send the type in the response headers and write the file's bytes to the client. How the client handles the file is up to the browser. In the vast majority of cases, the browser will know what to do (display an image, display via a plugin a PDF, save a .doc, etc.).
At the moment i get file extension of the file like :
string fileExt = System.IO.Path.GetExtension(filUpload.FileName);
But if the user change the file extension of the file ( for example user could rename "test.txt" to "test.jpg" ), I can't get the real extension . What's the solution ?
You seem to be asking if you can identify file-type from its content.
Most solutions will indeed attempt the file extension, but there are too many different possible file types to be reliably identifiable.
Most approaches use the first several bytes of the file to determine what they are.
Here is one list, here another.
If you are only worried about text vs binary, see this SO question and answers.
See this SO answer for checking if a file is a JPG - this approach can be extended to use other file headers as in the first two links in this answer.
Whatever the user renames the file extension to, that is the real file extension.
You should never depend on the file extension to tell you what's in the file, since it can be renamed.
See "how can we check file types before uploading them in asp.net?"
There's no way to get the 'real' file extension - the file extension that you get from the filename is the real one. If file content is your concern, you can retrieve the content type using the .ContentType property and verify that it is a content type that you are expecting - eg. image/jpg.