Let's say I have
c:\prod\foo.txt
and
c:\work\foo.txt
I would like to get c:\prod\foo.txt automatically and immediately updated from the other file, whenever I change & save c:\work\foo.txt
How can this be accomplished? Installing tools is okay. Windows 7 and up.
Symbolic linking is not a solution for me, as the c:\work is deleted every now and then.
Have you looked at SyncToy?
A: Run SyncToy silently addresses this issue.
SyncToy can be used in conjunction with the Windows Scheduler to automate sync operations.
Related
I have a Mac with Yosemite on it. Upon downloading SmartCVS 7.1.9 from https://www.syntevo.com/smartcvs/ , I try to run the application and receive an error that states "SmartCVS seems to already be running. Instead of running separate instances you can open multiple project windows in SmartCVS. If you are sure that no SmartCVS instance is running any more you should delete the lock file $FILE_PATH$/_lock_".
I've tried to delete the _lock_ file multiple times and that doesn't help (the lock file is empty. The application hasn't ever successfully run. Rebooting doesn't help. Deleting it from the computer and downloading it again doesn't help. Downloading previous versions has yielded the same error (7.1.3). I've tried running it from the terminal to get the crash log, but it doesn't make much sense.
In case it helps, upon downloading the first time I had a pop up stating that SmartCVS was by an unidentified publisher and couldn't open. I got around this problem found here: http://www.imore.com/how-open-apps-unidentified-developer-os-x-mountain-lion
I know that the program can work on my Mac OS since my boss has it running on her computer. Though, strangely, she did not have to deal with either of the two problems I've had to deal with.
Thanks
so at the time I posted this I also reached out to a SmartCVS community support group. They were able to solve the problem as follows:
My computer is part of a Network. As such, the files are technically stored locally since my User Home is on the Network. SmartCVS can't interact with the lock file since it's not on the local machine. Therefore in the file at "~/Library/Preferences/SmartCVS/7.1/smartcvs.properties", I needed to append the following line to the end of the file:
smartcvs.applock=false
I got a weird problem with my VB app that has got me very confused. I am updating an existing program. I had to add some processing queue capabilities. On my system, unit testing worked great but when I compile it and run it on a different computer (a network server machine) it first tries to open an office install. If I cancel this, the program seems to run fine. The problem is that this program will be run in the background and I can't be hitting cancel each time it runs.
So my question is this: what is going on here? I'm usually a java developer we eclipse so I'm used to being able to include all the needed libs into the jar files automatically. It doesn't seem like the case with VB6. it seems like it expects all the same libs to be on all the systems. Is there any way to tell what might be triggering this?
The only thing I can think of that is causing it is that I'm using the "OpenProcess" function in the kernal32 lib. that the only major change I have made.
any help would be very appricated. thanks!
EDIT:
It seems that multiple versions of word were installed on the system and it was screwing things up somehow. We uninstalled one and it fixed it.
I ran into this a while ago and it was related to my installer for the VB6 app overwriting some system files for Office that it shouldn't have. Any time one of the System dlls was accessed Windows would determine that something was wrong and the Office installer would start up.
The short-term fix was to let the Office Installer repair the broken chain of dlls.
The long-term fix was to never overwrite built-in Windows System dlls.
You could also check out the Microsoft Fix it Center.
I've had a custom auto-update feature for my programs ever since Windows 95. It used to work fine, until Vista and then Windows 7. What it basically did was to download the new executable, create a batch file and execute it. The batch file simply waited for parent executable to close (by constantly trying to delete it) and then move/rename the downloaded new one as the old one. And even run the newly downloaded one. This worked fine for years. But Windows 7 doesn't really like me to do that. One thing is that it "knows" the executables are no longer same (even though their names and paths are same).
Is there a way to silently replace an executable with a new one by copying the executable properties/permission to the new one, so that Windows 7 won't complaint about it being a different exe? (Of course I need this for auto-update feature, so I'm open to other approaches as well)
Hmm ClickOnce w/ .NET works great for this... Don't know what you mean by windows 7 complaining about the exe however.
Not sure about the warnings you describe but I have had problems where I placed the update in a separate directory which broke the pinned item in the task bar.
One approach is to have thin loader which is installed once and then loads the updated program into its own memory space. That way it will be identified as the same program if pinned in the task bar.
I'm only familiar with using .NET AppDomain but I assume most other runtimes can do it as well.
I have seen references online that state that 'Scheduled Tasks' in Windows are stored in %SystemRoot%\Tasks, which I think usually equates to C:\Windows\Tasks.
However, I observe that while that folder exists on my Windows 7 system, Scheduled tasks doesn't use it.
My system appears to use, C:\Windows\System32\Tasks.
I have studied the Environment variables and there doesn't seem to be anything related to Scheduled Tasks there.
How do I discover which folder is used for Scheduled tasks?
Tasks are saved in filesystem AND registry
Tasks are stored in 3 locations: 1 file system location and 2 registry locations.
File system:
C:\Windows\System32\Tasks
Registry:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tasks
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tree
So, you need to delete a corrupted task in these 3 locations.
I want to extend #Jan answer:
It's seems, that Task Scheduler 1.0 API uses C:\Windows\Tasks folder for create and enumerate tasks (this example), while Task Scheduler 2.0 API uses C:\Windows\System32\Tasks to create and enumerate tasks (this example).
It's also seems, that windows console utility schtasks and GUI utility taskschd.msc uses Task Scheduler 2.0 API.
P.S.
I found, that if task placed in C:\Windows\Tasks and have not set AccountInformation, then task won't be displayed in windows console and GUI schedulers. If you set AccountInformation (even "" for SYSTEM account) and set flag TASK_FLAG_RUN_ONLY_IF_LOGGED_ON - task will be displayed in all standard applications.
Solution found here
For Windows 7 and up, scheduled tasks are not run by cmd.exe, but rather by MMC (Microsoft Management Console). %SystemRoot%\Tasks should work on any other Windows version though.
There are multiple issues with the MMC however as on almost every PC in my business the ask scheduler API will not open and has somehow been corrupted. So you cannot edit, delete or otherwise modify tasks that were developed before the API decided not to run anymore. The only way we have found to fix that issue is to totally wipe away a persons profile under the C:\Users\ area and force the system to recreate the log in once the person logs back in. This seems to fix the API issue and it works again, however the tasks are often not visible anymore to that user since the tasks developed are specific to the user and not the machine in Windows 7. The other odd thing is that sometimes, although not with any frequency that can be analyzed, the tasks still run even though the API is corrupted and will not open. The cause of this issue is apparently not known but there are many "fixes" described on various websites, but the user profile deletion and adding anew seems to work every time for at least a little while. The tasks are saved as XML now in WIN 7, so if you do find them in the system32/tasks folder you can delete them, or copy them to a new drive and then import them back into task scheduler. We went with the system scheduler software from Splinterware though since we had the same corruption issue multiple times even with the fix that does not seem to be permanent.
Looks like TaskCache registry data is in ...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache
... on my Windows 10 PC (i.e. add Schedule before TaskCache and TaskCache has an upper case C).
On newer versions of Windows (Windows 10 and Windows Server 2016) the tasks you create are located in C:\Windows\Tasks. They will have the extension .job
For example if you create the task "DoWork" it will create the task in
C:\Windows\Tasks\DoWork.job
My application running on a Windows server makes use of a Jet/Access database. For some reasons around every two weeks that database file gets locked by the System process (PID 4, seems to be fixed)
After some googling I found some other users having their files locked by that special process, but different files (of course).
What's the general reason for the System process to keep an open file handle?
Is my application the cause for this locking situation?
Are all handles implicitly opened by the System process? I could imagine that after a process has crashed, the handle may still be open and the System process somehow takes owernship of that handle.
Can I do something in my application to prevent it from happening?
Files accessed through a share will be locked by the system process (PID 4).
Try opening compmgmt.msc -> System Tools -> Shared Folders -> Open Files to see if the locked file is listed there
See also the sysinternals forum for a way to replicate this.
Not all applications lock files when they are opened, Excel however does. I don't know if Access does the same...
Here's another possible cause I've found:
There is a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service and causes the same problems as described in the question.
Re-enabling this service has fixed this problem for me.
A bit more info here as to why it's causing a problem.
List of other SO questions which seem to be related:
Visual Studio output file permissions?
Windows 2008 R2 - Kernel (System Process PID=4) is locking files and folders
This sounds to me like a driver-level issue with a leaky handle.
If you're running an anti-virus package try upgrading, disabling (temporarily!) or switching to a different brand.
It may be a lingering session from a remote computer to a shared folder. If that's the case, it can be unlocked from the command line:
net session /delete
Is your server set up to perform periodic file backups?
If so, is the backup running as System, perhaps prompting the locked file when you get a conflict?
For me, it was "Windows Defender" (anti-virus). I excluded my Visual Studio build folders from Windows Defender's list of folders it checks, and the problem went away. (Visual Studio wasn't able to build to the EXE file, PID 4 was locking it to check for virii)
For me I had to hit it with a sledgehammer. Chkdsk /f on the drive where the folder was located fixed it. Use with caution.
Check the security settings for each folder and subfolders. Make sure that the system did not just automatically create a special permissions setting which will not allow anyone to delete the file. Apparently for some odd reason the OS creates a weird special permission setting that protects the file from being deleted.