swap file writes
I have noticed that swap file writes are done in 4K blocks, but file reads are done in 64K blocks. If it isn't possible to adjust this behavior with configuration, then I suggest opening this up as a performance issue that could be addressed in future releases of gvim? Opening a large file would be much faster if this were changed. It would also reduce disk/file fragmentation. sk --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: swap file writes
skelker wrote: I have noticed that swap file writes are done in 4K blocks, but file reads are done in 64K blocks. If it isn't possible to adjust this behavior with configuration, then I suggest opening this up as a performance issue that could be addressed in future releases of gvim? Opening a large file would be much faster if this were changed. It would also reduce disk/file fragmentation. sk Swap file writes cannot be delayed, or the swap file would lose its utility: thus swap file writes happen more often (sometimes much more often) than edit file read/writes or swap file reads. OTOH, swap file writes are usually limited to a rather small area at the end of the file. Thus it is essential for performance (and also to minimize the risk of getting a power-fail halfway through a swap file write) to keep the swap file buffer as small as reasonably possible, while the ideal size for the edit file (which is always written /in toto/, but much less often) is quite bigger. Making the swapfile buffer larger would IIUC not much reduce disk fragmentation either, since the swapfile is deleted as soon as the corresponding editfile is unloaded (either to load a different file in its stead if not using hidden buffers, or when normally closing Vim). Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 156. You forget your friend's name but not her e-mail address. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: swap file writes
On Dec 4, 2007 5:40 PM, Tony Mechelynck [EMAIL PROTECTED] wrote: skelker wrote: I have noticed that swap file writes are done in 4K blocks, but file reads are done in 64K blocks. If it isn't possible to adjust this behavior with configuration, then I suggest opening this up as a performance issue that could be addressed in future releases of gvim? That's not quite true, is it? The number of pages in a block times the page size (hopefully the page size of the file system) bytes are written at a time. Swap file writes cannot be delayed, or the swap file would lose its utility: thus swap file writes happen more often (sometimes much more often) than edit file read/writes or swap file reads. OTOH, swap file writes are usually limited to a rather small area at the end of the file. Thus it is essential for performance (and also to minimize the risk of getting a power-fail halfway through a swap file write) to keep the swap file buffer as small as reasonably possible, while the ideal size for the edit file (which is always written /in toto/, but much less often) is quite bigger. Bullshit. Unless you also fsync [1] there's no guarantee that anything you've written will be on disk at power-failure time. So the number of bytes written at a time is not relevant. In fact, writing fewer bytes is going to increase your chances of data loss, as you're making more system calls, which wastes a lot of time. Regardless, I wonder how much of an issue this really is. It seems to me that the code is quite optimized [1] fsync is a slow operation, especially on a reiser4 file-system. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: swap file writes
On Dec 4, 2007 7:40 PM, Tony Mechelynck [EMAIL PROTECTED] wrote: Regardless, I wonder how much of an issue this really is. It seems to me that the code is quite optimized How much of an issue the size of the writes, that is. [1] fsync is a slow operation, especially on a reiser4 file-system. On a reiserfs or ext3 filesystem, it is (IIUC) less critical because of the way the journalizing filesystem can repair when restarting after a failure. ReiserFS is Reiser3, the predecessor of Reiser4. I don't understand why you're saying what you're saying here. None of these filesystems can repair anything that isn't in the journal, so you're still not guaranteed anything. The journaling in Reiser3 and Ext3 can still mess up your files. Reiser4 will, however, guarantee consistent states (that is, your data will be there or it won't - it won't become corrupted). Reiser4 guarantees ACID, in database terms. Reducing calls to write is at least as critical for journaled file-systems as any. More calls means (possibly) more entries in the log, which will decrease performance and possibly increase chances of data loss. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.168 (extra)
Juergen Jottkaerr wrote: On 3 Dez., 22:20, Bram Moolenaar [EMAIL PROTECTED] wrote: Patch 7.1.168 (extra) Problem:Win32 GUI: Since patch 7.1.095, when the Vim window does not have focus, clicking in it doesn't position the cursor. (Juergen Kraemer) Solution: Don't reset s_button_pending just after receiving focus. Files: src/gui_w48.c clicking into the text area of Vim works correctly now, but there is still a problem with clicking inside the (right) scrollbar. Here's how to reproduce it: gvim -u NONE - U NONE :let i = 0 :while i 100 : let i += 1 : put ='Line ' . i :endwhile :normal ggdd :set lines=20 Now move focus to a different application and get back to Vim by clicking in the right scrollbar just below the slider: the slider is moved down, but line 1 is still the top line. Click again just below the slider: the slider is moved again and now line 35 is the top line -- lines 20 to 34 have been jumped over have and never been displayed. If instead of clicking a second time you enter Lj in normal mode, line 20 is moved into view *and* the position of the scrollbar slider is corrected. Can you have a look at this? I see the problem. It's not obvious how to solve this. One more item for the todo list. -- Wizards had always known that the act of observation changed the thing that was observed, and sometimes forgot that it also changed the observer too. Terry Pratchett - Interesting times /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Dec 3, 2007 4:59 PM, Charles E. Campbell, Jr. wrote: Matt Wozniski wrote: On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Sure, I understand that you could use it as a key to encrypt the password, but what I'm really asking is what you gain from that. Is it really more secure to have an encrypted string and its decryption key stored in memory than it is to have an unencrypted string in memory? Particularly on an open-source project where anyone who wants to can view your source code? Where's the part where I said I'd store the session pid in some variable? Something like getpid() would be called during encrypt/decrypt, not stored. My point was that a would-be cracker would have access to both the encryption key and the encrypted text. Using the pid as the key is not made more secure by not storing it, since that cracker would also have access to the hypothetical getpid() function; it just saves him the trouble of accessing a variable to get the key. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
My point was that a would-be cracker would have access to both the encryption key and the encrypted text. Using the pid as the key is not made more secure by not storing it, since that cracker would also have access to the hypothetical getpid() function; it just saves him the trouble of accessing a variable to get the key. ~Matt I'm not sure the point is really to stop a cracker. If someone has access to your terminal with your user privileges and the password is stored, encrypted or not, they can get at it, unless decrypting it requires typing a password which defeats the point, of course. Rather, I would think the value in this is more so that if you're working with somebody else observing and for some reason issue :let or such, your password doesn't magically appear on the screen in plaintext for all to see. Passwords usually don't appear on the screen in plaintext as you're typing them, and they shouldn't be easy to accidentally bring up in plaintext for anyone who happens to be watching to see. To solve the problem, the encryption needn't be strong--it just needs to be good enough that casual inspection wouldn't reveal it, i.e. not just rot13. Likewise, a plaintext password shouldn't be stored in a session file--better to store some garbage that can't be decrypted next time, and require the user to retype the password once per session. So, far from being an attempt to stop a cracker who has access to your session, which is a hard kind of cracker to stop, it's more an attempt to stop accidental discovery of your password, or to stop yourself accidentally revealing it (e.g. by saving a session--who'd have thought that could reveal your password?). That's my take on it, anyway. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Thank you, Ben! That's exactly what I meant. For this, keeping a variable in a script-local function would suffice -- I personally haven't found a way yet to access a s:var. (If you know of a vim-only solution, please tell me.) Although rot13 is of course is no encryption/obfuscation at all, IMHO a randomized replacement table method probably won't be any less secure than saving the passwords to disk (ready for take-away and later inspection). Also, you will most likely have to define functions that decrypt the stuff. So, if bad people really gained access to your terminal, nothing would stop them from calling these functions (calling script-local functions isn't difficult). This could be less safe than keeping them plain text in a script-local variable (which I don't know how to access from within an unpatched vim). BTW maybe I missed something but if you store passwords in a script local variable how could they show up in session files? Against which kind of attacks would you like to protect the passwords? #1 echo :echo g:my_passwords #2 session :exec 'edit '. v:this_session #3 core dump inspection? #4 ... thomas. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
