I'm looking for a editor in windows that constantly saves file.
In linux I do
cat>somefile
and then just start typing. somefile gets filled up as I type.
Is there editor or similar thing in WIndows? Preferably a non-dos tool?
I use WebStorm from JetBrains, which saves constantly and unobtrusively.
I really love it. I use it as a text editor and for my web development.
http://www.jetbrains.com/webstorm/
(and no I don't work there).
Its possible to install some unix features to windows.
Have a look at this CoreUtils
The shareware text editor UltraEdit by default works with using a temporary file which means create a copy of the file to edit in directory %TEMP% and copy this temporary file on save back to original file. The usage of a temporary file makes it possible to use Undo and Redo.
But it is possible at Advanced - Configuration - File Handling - Temporary Files to disable the usage of a temporary file for all files or just for large files depending on a threshold value in KB. All edits made on a file opened without usage of a temporary file are permanent which means immediately done on storage media.
Another feature of UltraEdit is automatic save in regular intervals which can be configured at Advanced - Configuration - File Handling - Save with or without making a backup on every save and even supporting version backups which means backups with an incrementing number on every save.
Last but not least on usage of a temporary file for editing a file as by default UltraEdit can recover last edits if UltraEdit crashes (uedit32.exe process killed with Windows task manager), or Windows crashes, or a sudden power loss occurs. The temporary file is updated quite often in the background by UltraEdit and therefore the restore on next start after an unexpected end of the editing session often restores nearly all edits made last on a file. The recovery feature includes also new files not being saved ever as file with a file name.
It would be interesting to know for offering a perhaps better solution why you want that any edit is immediately written to the file. In general this is the opposite of what users want on editing a text file and is not good on some storage medias like SSD hard disks.
Related
I started using robocopy with /Z switch and log option. I started copying 109+ GB file , it is more than two days and still getting copied. Since I ran copy with log option (/LOG+) , I cannot see percentage of completion. Is it safe to open log , while copy is in progress to see percentage of completion. Do not want file copy interrupted by opening log file. Is it safe to copy the log file to a different location and open it. Can some one clarify me on this?
Whether or not it is possible to open it, depends on the program you're using for that matter: programs like Notepad and Notepad++ are able to open a file, while another process is still writing to it, MS-Word is not able to do that. The largest difference between Notepad and Notepad++ for this matter is that Notepad can't refresh the file (or reload from disk, as it is called in Notepad++).
In case you have a Linux subsystem on your PC, you might use the tail -f feature, which is written especially for this purpose.
Ok, complete Visual Studio & Windows development noob here - there's gotta be an easy answer to this.
I've just started working on porting a Linux C++ library to Windows. Existing source tree is on the Linux file system, VS is running in a Windows 7 VM, which has the Linux file system mounted.
I added the source tree to a new project - I was initially doing the edits on the linux side, but now I've done a few from the VS IDE. But those edits aren't showing up on the disk?? I've done the typical save: ctrl-s, done the "save all": ctrl-shift-s, saved from the menu, etc. If I look at the file on the disk on the linux side, the changes aren't there.
I've shut down & restarted VS, and it still sees the changes on restart. How do I get the changes back on the actual disk so I can commit to subversion, etc.?
I've confirmed that the files & file system are read/writable from the Windows VM.
I'm sure this made sense to somebody, but I'll be damned if I get it.
Visual Studio Professional 2013 on Windows 7
You shouldn't be reading/writing to the same directory under both environments, imo. Not the least reasons of which is that *nix & windows have different ideas of line endings.
It would be much better to keep a git repository on your host OS (or on a server like github) and pull/push to that repo from your windows VM. Git is smart enough to handle all the line endings, symbolic links, permissions, etc. automagically.
I have seen similar behavior using BC++ IDE.
In my case I was trying to edit files that were hard links to files in a second directory (on the same NTFS file system).
The IDE is using some mechanism to reposition the file to be edited into the _history backup directory.
I.e. the editor unlinks the original file in the original directory and relinks it in the _history subdirectory and creates a completely new directory entry for the edited file.
The hard linked file I created in the second directory is thus then linked to the backup file in the _history directory so when I edit the file in the second directory with notepad, the modifications appear in the _history backup file (or vica versa) but not the file in the originial location.
Its not like a simple text editor (notepad) where the edited file is opened-read-closed and when saved, reopen-written-closed using the same directory entry.
I presume that the IDE is using a low level Windows file system function to rename/link the original file into the _history
directory and that this mechanism does not support/recognize NTFS hard links. I suspect in your case that VS may use a similar relinking mechanism (specific to NTFS) that similarly would not work with the files in the mounted Linux file system.
That VS may be storing edits in a temporary file (may be hidden or in some other temporary directory) so the original file is not lost if the IDE crashes. When the file save is committed it attempts to link the original file to backup and then attempts to relink the temporary edit file into the original directory entry location, but because the NTFS file system linking mechanism is not compatible with the Linux file system, nothing happens.
[I do observe temporary files appear like this when editing MicroSoft Office documents. notepad++ also does this, so I suspect VS is doing the same thing.]
I'm updating some legacy code to more efficiently use .ini files for parameter storage. Basically, it caches all the settings internally once they're read so that they can be read again without opening the file. Before using the cache, I compare the cache creation time to the last modified time of the file, and recreate the cache with the updated file. This works great, except when users rename files, because that action doesn't update the last modified time.
So if I copy my app.ini to app - copy.ini, modify app - copy.ini outside of my program, then delete app.ini and rename the copy to app.ini, my program is now using an outdated cache. Even if my program caught the deletion of app.ini and cleared the cache, it would not rebuild the cache when the copy was renamed. The program is designed to run for a very long time unattended, so I would like to avoid continually monitoring the file - only check it once I need to read a parameter.
What you are needing is a filewatcher for vb6, you could try it by interop with .net or use something like this VB6 Implementation
For that scenario, you could keep a hash of the contents of each .ini file the program is using and periodically check each file. If the hash is different than what it was last time you checked, then it's contents were changed or it's a different file caused by this rename scenario.
I need to be able edit the content of index.dat file programmatically (C:\Documents and Settings\Username\Cookies\index.dat). More precisely I need to modify it in order that index.dat for one user can be used for a different user name. Is there any documentation out there for this kind of binary file?
Pasco (http://www.foundstone.com/us/resources/proddesc/pasco.htm) is a free index.dat parser that comes with the source code.
Docs will be hard to come by - Microsoft has never publicly documented the structure of the the structure of this file. That said, you can find docs on the web such as the one mentioned above.
However, note that IE keeps close tabs on this file. The file is locked while IE is running (meaning, you can open/read it in some modes but not in others) and you can certainly not write to it.
One method that might still work is to boot-up in safe mode and then assign yourself administrator rights and then see if you can find the files to delete them.
The method I now use is to create a batch file to rename the subfolder below the folder containing the index.bat files and to then only copy the folders back to the original location that don't contain these files but the resultant batch files needs to be run from a separate windows account that has full administrator permissions.
The freeware code editor PSPad will allow you to view and to edit the contents of all of the index.dat files on your computer in hexadecimal form. This is done by replacing all of the digits in the first eight columns with zeros. This removes all of the information contained in the files.
It's a tedious process, requiring holding down the "0" (zero numeric key) as all of the edits are made, but anyone then accessing any of the index.dat files will get no information.
IE must be closed when doing this or you may receive an error message when attempting to save the modified file(s).
I have a Windows service application on Vista SP1 and I've found that users are renaming its executable file (while it's running) and then rebooting, thus causing it to fail to start on next bootup because the service manager can no longer find the exe file since it's been renamed.
I seem to recall that with older versions of Windows you couldn't do this because the OS placed a lock on the file. Even with Vista SP1 I still cannot copy over the existing file when it's running - Windows reports that the file is in use - makes sense. So why should I be allowed to rename it? What happens if Windows needs to page in a new code page from the exe but the file has been renamed since it was started? I ran Process Monitor while renaming the exe file, etc, but Process Mon didn't report anything strange and just logged changing the filename like any other file.
Does anyone know what's going on here behind the scenes? It's seem counter intuitive that Windows would allow a running process' filename (or its dependent DLLs) to be changed. What am I missing here?
your concept is wrong ... the filename is not the center of the file-io universe ... the handle to the open file is. the file is not moved to a different section of disk when you rename it, it's still in the same place and the part of the disk the internal data structure for the open file is still pointing to the same place. bottom line is that your observations are correct. you can rename a running program without causing problems. you can create a new file with the same name as the running program once you've renamed it. this is actually useful behavior if you want to update software while the software is running.
As long as the file is still there, Windows can still read from it - it's the underlying file that matters, not its name.
I can happily rename running executables on my XP machine.
The OS keeps an open handle to the .exe file,. Renaming the file simply changes some filesystem metadata about the file, without invalidating open handles. So when the OS goes to page in more code, it just uses the file handle it already has open.
Replacing the file (writing over its contents) is another matter entirely, and I'm guessing the OS opens with the FILE_SHARE_WRITE flag unset, so no other processes can write to the .exe file.
Might be a stupid question but, why do users have access to rename the file if they are not suppose to rename the file? But yeah, it's allowed because, as the good answers point out, the open handle to the file isn't lost until the application exits. And there are some uses for it as well, even though I'm not convinced updating an application by renaming its file is a good practice.
You might consider having your service listen to changes to the directory that your service is installed in. If it detects a rename, then it could rename itself back to what it's supposed to be.
There are two aspects to the notion of file here:
The data on the disk - that's the actual file.
The file-name (could be several or none) which you can give that data - called directory entries.
What you are renaming is the directory entry, which still references the same data. Windows doesn't care about your doing so, as it still can access the data when it needs to. The running process is mapped to the data, not the name.