I like to include my Firefox profile directory in my automated backups but I don't really want to back up cached pages/images. I've searched high and low but everything I've found is either outdated (delete the contents of the [ffprofile]\Cache folder) or the instructions delete the entire contents of the profile directory! There must be some way to do this with modern FF builds...
I don't think there is a command line option to clear the file caches directly (patches accepted, though, I suppose. ;> ). As a workaround, though, you can clear the caches through this method via the command line:
# Create a test profile (Do this once)
PROFILENAME=testProfile
PROFILEDIR=/tmp/profileDir
$ firefox -no-remote -CreateProfile $PROFILENAME $PROFILEDIR
# Clear the cache of the profile (Do this every time you want to run the script)
# This uses the mac osx path for caches
# See http://forums.mozillazine.org/viewtopic.php?f=38&t=502357 for more information about where the caches are located on different operating systems
rm ~/Library/Caches/Firefox/Profiles/*.${PROFILENAME}/entries/cache2/*
Note that I tested this on Mac OSX, and it works fine, although it's somewhat of a hack to get around the lack of a profile identifier.
For anyone else who might struggle with this: just go to about:cache - the location of the cache files is listed in the 'disk' section under 'Storage disk location'. Once you have the location, append "\entries" and do a simple "del /f /q [location]"
Related
I maintain a private Git repository with all of my config and dotfiles (.bashrc, profile.ps1, .emacs etc.).
On Windows this repository is stored under C:\git\config. Most applications expect the files to be elsewhere, so I added hard links between the repository and the expected locations.
Example
On Linux .emacs is located in ~/git/config/.emacs but emacs expects it to be at ~/.emacs. I run:
$ sudo ln -s ~/git/config/.emacs ~/.emacs
On Windows my .emacs is located in C:\git\config\.emacs, but emacs expects it to be in C:\users\ayrton\.emacs. I run:
PS> cmd /c mklink /H C:\users\ayrton\.emacs C:\git\config\.emacs
Issue
On Linux this seems to work fine: when I update the original file, the contents of the link update and everything stays in sync.
On Windows, the links break after a period of time and the files become out of sync (the file contents are different).
Why do the links break on Windows? Is there an alternative solution?
I've seen this StackOverflow post: Can't Hard Link the gitconfig File
So I’ve finally found a solution that takes the best of both: put the repo in a subdirectory, and instead of symlinks, add a configuration option for “core.worktree” to be your home directory. Now when you’re in your home directory you’re not in a git repo (so the first problem is gone), and you don’t need to deal with fragile symlinks as in the second case. You still have the minor hassle of excluding paths that you don’t want versioned (eg, the “*” in “.git/info/exclude” trick), but that’s not new.
The problem here is that the expected locations are different on Windows vs. Linux. For example, VSCode expects the user settings to be in:
Linux: $HOME/.config/Code/User/settings.json
Windows: %APPDATA%\Code\User\settings.json
Ideally I would like my repository to be platform independent. If take the core.worktree approach (e.g. make core.worktree be / or C:\, then exclude everything except specific files) I would have to maintain two copies of some configuration files when their absolute paths differ across operating systems.
Hardlinks can break if a editor opens/creates the file as a new blank file each time you save. It would not surprise me if Notepad did this because it reads the entire file into memory and has no need for the original file after it has loaded the file.
You can try to create a file symlink instead of hardlink on Windows.
First of all, I would like to apologize if I'm on the wrong stackexchange network, and secondly, sorry if I'm overlooking something simple.
I was moving files from my old hard drive from an old PC when I came across several password protected ZIP Files. However, since those files were a bit old, I forgot the passwords already. I tried every password I could come up with but I still came up empty. After several google searches, I found this tool/utility for Mac OS X that could help me. So I go to the downloads page and download the Mac OSX utility tool and the source code.
However, I am having problems executing the make command for the file. It says on the downloads page:
If you are using linux or another unix, you need to download the source code, uncompress it and type "make" to compile the utility.
So far, what I've tried is
$make /Users/myname/Downloads/aapr-0.01-source/Makefile
I have also tried the other files in the source folder but nothing worked. After that, I'm pretty much blank. I tried double clicking the aapr file in the utility download for Mac (which is a Unix Executable) and it opens a new terminal window displaying the commands and such. Also, doing $aapr [options] [filename] only shows me -bash: aapr: command not found. I also updated XCodes command line tools.
Sorry if I'm missing out on something very basic, I don't usually use the terminal on the OS X.
Try running
cd /Users/myname/Downloads/aapr-0.01-source
make
A Makefile contains rules for building files from other files but it is based on paths and contents, etc. which depend on your current location. So generally you need to be in the directory of the project for it to work.
Edit (copied from my comment):
To execute a command from a specific location (that isn't in the normal $PATH) you need to specify a path for it. So something like /bin/bash or ./aapr (where ./ means the current directory).
I set the HOME variable in /etc/launchd.conf using the following line: setenv HOME /Users/student
Now the machine wont boot at startup. I tried holding shift at startup but safe mode doesn't seem to be working. I tried holding cmd+s on startup and got into single user mode. I was able to bring up the /etc/launchd.conf file but I can not save/overwrite the existing file due to permission issues.
Is there some way to reset this file from single user mode or other to fix this? I'm open to other approaches as well. I am not a unix/linux power user by any means, fyi :)
Thank you in advance.
I'll give you two options, but first a warning: both of these involve using the command line to undo the damage, and if you do it wrong there's a possibility you'll make it even worse. A backup would've been a good idea, but it's a little late for that (well, actually, there are still ways to do it, but they also involve a risk of getting it wrong...). So whatever your do, be careful.
Option 1: use single-user mode (Command-S at startup). This will leave you running as root, which means you are not subject to normal file permissions; after remounting the startup disk for write access (mount -uw /) you should not get permissions errors. You said this didn't work; the most likely thing is that you mistyped the command (I see this happen a lot -- people either leave out the "/", or the space between "-uw" and "/"). Hint: if the mount command prints anything (other than the prompt for the next command) you typed it wrong. If that still doesn't do it, check the file's flags and metadata with ls -leO# /etc/launchd.conf and report the results.
Option 2: use recovery mode (Command-R at startup). This boots from a small hidden partition with a minimal copy of OS X. In recovery mode, pull down the Utilities menu and choose Terminal. This is actually a fair bit like single-user mode, except that the normal startup disk won't be /, it'll be /Volumes/Macintosh HD (or whatever it's named), and it'll already be mounted for write access. Since there's (probably) a space in the volume name, you'll have to quote or escape it:
$ cd "/Volumes/Macintosh HD"
$ mv launchd.conf launchd.conf-disabled
When I print out all files in the windows 7 system32 directory using ruby, some files are missing. I use this simple directory iteration:
Dir.foreach("C:\\Windows\\System32") do |fname|
puts fname
end
I am specifically looking for python27.dll, which is not printed, though it exists. File.exists? seems to have the same problem as the dir iteration. it returns false for an existing file:
File.exists? "C:\\Windows\\System32\\python27.dll" #returns false
Checking for another existing file of the folder works:
File.exists? "C:\\Windows\\System32\\quartz.dll" #returns true
But it does not work if I duplicate an existing file or create a new one in system32
File.exists? "C:\\Windows\\System32\\quartz2.dll" #returns false
Also, copying python27.dll to another directory and checking for existence works:
File.exists? "C:\\Otherfolder\\python27.dll" #returns true
The problem has nothing to do with letter-case or the path delimiter. I checked that. Also, I don't see differences in the user-rights for files that work and that don't ...
I really have no idea, why this happens ... can anyone reproduce this???
thanks
[edit]
Took a while, but I found the answer.
It was a 32/64-bit issue. for ruby as a 32bit application, "C:\Windows\System32" is actually "C:\Windows\SysWOW64". As the 64bit WinExplorer showed, python27.dll was in System32 (which only 64bit processes see - well, confusing), wheras it should have been in SysWOW64 for ruby to see. Installing the 32bit version of Python fixed the problem for me (as I couldn't change the ruby script, because it was part of rubypython).
In Windows 7 (Vista, actually), a lot of security policies that existed only on paper in earlier versions of Windows, are now actually enforced by the operating system. For example, according to Microsoft's documentation, it has been pretty much illegal to write to C:\Windows\System32 for decades now, but if you actually tried it, it still worked. Not anymore. As of Vista, C:\Windows\System32 is off-limits.
However, in order not to break existing (broken) applications, Microsoft introduced filesystem virtualization. If an application tries to write to C:\Windows\System32, it gets silently redirected to C:\Users\%Username%\AppData\Local\VirtualStore\Windows\System32. So, this specific application sees all the files it created or changed in C:\Windows\System32, but other applications see only the unchanged / empty directory.
This does not just apply to C:\Windows\System32 but also to other system directories as well. Also, it applies to system parts of the registry, like HKEY_LOCAL_MACHINE for example.
This virtualization is per-application. I.e. if Application A tries to create or modify a file in a protected directory, Windows will intercept that call and redirect it to the VirtualStore. It will also record this redirection somewhere. Now, when that same application A tries to look there again, Windows will use the recorded redirection, so that the application thinks the file is where it put it, when in fact, it is somewhere else entirely.
However, if a different Application B looks at that directory, then the redirection is not triggered and B just sees a pristine system directory. This is the whole point: in the past, different applications would create all sorts of weird bugs by overwriting each other's files in system directories. I.e. one application would dump its python27.dll into C:\Windows\System32 and another application would dump its own, slightly different incompatible version of python27.dll, overwriting the first one.
So, you used one application to copy the DLL there (probably explorer.exe) and you use a different application, namely ruby.exe to look at it. But explorer.exe didnt't actually copy it into system32, it got redirected to the VirtualStore. When you use explorer.exe, the redirection gets triggered and you see the file right where you think you put it, but when you use ruby.exe, the redirection does not get triggered and it sees the directory as it actually is.
I bet that
File.exists? "C:/Users/#{ENV['Username']}/AppData/Local/VirtualStore/Windows/System32/python27.dll"
returns true.
Are you sure the files are available in C:\\Windows\\System32\\?
I don't know this problem from the System32-folder, but I had some problems like yours with the Program Files-folder.
If you try to save data in some system folders and you are no Admin, Win7 don't store it at that location, but in a user specific Virtual Store. When you look at your system folder, files from the virtual store are also shown there. But the path is another one.
You may check your virtual store anywhere in c:\users\<username>\Appdata\local\Virtual Store\ (at least the Program-folder is there).
I've had same problem, it turned out that ruby can behave this way when working with paths longer than 260 symbols:
Administrator#WIN-NUMKGBH6IIM ~
$ mkdir -p /cygdrive/c/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/
Administrator#WIN-NUMKGBH6IIM ~
$ /cygdrive/c/opscode/chef/embedded/bin/ruby <<'EOF'
puts File.exists?("C:/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/")
EOF
true
Administrator#WIN-NUMKGBH6IIM ~
$ /cygdrive/c/opscode/chef/embedded/bin/ruby <<'EOF'
puts File.exists?("C:/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/")
EOF
false
I don't seem to have this problem on my home laptop with Windows XP, but then I don't do much work there.
On my work laptop, with Windows XP, I have a problem deleting directories when it has directories that contain .svn directories. When it does eventually work, I have the same issue emptying the Recycle bin. The pop-up window says "Cannot remove folder text-base: The directory is not empty" or prop-base or other folder under .svn
This continued to happen after I changed config of TortoiseSVN to stop the TSVN cache process from running and after a reboot of the system.
Multiple tries will eventually get it done. But it is a huge annoyance because there are other issues I'm trying to fix, so I'm hoping it is related.
'Connected Backup PC' also runs on the laptop and the real problem is that cygwin commands don't always work. So I keep thinking the dot files and dot directories have something to do with both problems and/or the backup or other process scanning the directories is doing it. But I've run out of ideas of what to try or how to identify the problem further.
You don't need to reboot; just open Task Manager and kill TSVNCache.exe.
This is safe, too. It's designed so you can kill it and it will automatically restart when needed.
(As a result of the auto-restart, note that browsing some SVN folders in Explorer, File-Open dialogs, etc. may cause TSVNCache.exe to restart. Keep an eye on Task Manager.)
Tortoise SVN is great but I have found that TSVNCache.exe can hold on to locks and get in the way at times. (Sometimes justified, sometimes not.) As a result, for some automated scripts I run I include commands to kill TSVNCache.exe as part of the scripts so it doesn't get in the way. That's only worth doing if it's an operation you perform often, though.
You can try a few things:
Since you are getting this error frequently, you can use handle.exe from sysinternals to check which process currently have open handles for the .svn\* directory. If handle utility tells you about any process, try stopping that process and then delete the directories.
Error while deleting from recycle bin: In simple terms, when a file is sent to recycle bin after deleting, it is not actually deleted, rather, a few manipulations are done in directory hierarchy (file system level) to avoid showing the file while browsing content of a folder. So If you happen to resolve the problem mentioned in comment#1, you will not get this error probably.
Cygwin command not working: Running a cygwin command on windows requires (in particular) cygwin1.dll, which is known to be shipped with other programs (eg: CopSsh, some version of svn clients etc...) as well. If there is any mismatch in the version of cygwin1.dll, cygwin commands won't work. Try searching for cygwin1.dll on your computer and try to resolve version conflicts (if any).
did you ever do mkpasswd and mkgroup for cygwin? If you're using cygwin from the command line you are pretty much guaranteed to have file system permissions issues. and you have to read a little to fix it.
http://cygwin.com/cygwin-ug-net/ntsec.html
Try this answer from me. Although it's given for TortioseGit instead of TortoiseSVN, the handling is the same:
disable the status cache (i.e. prevent the TSVNCache.exe from accessing the .svn folders continuously)
delete what you have to delete
enable the status cache to get updated overlays again
I have just experienced this problem (or similar)
I am using tortoise 1.6.7
To fix it I went to 'Tortoise Settings' from the tortoise context menu.
from there select "Icon Overlays" in the tree widget.
In the icon overlays page, I entered the path that was giving me angst into the "exclude paths:"and tortoise no longer holds that directory handle.
This is a directory that is often deleted by a process other than explorer.
Since what it appears that you are trying to do is export the repository from SVN, why not use the export functionality with TortoiseSVN. This removes all .svn directories from the generated 'working copy'.Cmdline: http://svnbook.red-bean.com/en/1.0/re10.html
If you want to delete all sub folders named .svn in windows
then create batch file with this content:
for /f "tokens=* delims=" %%i in ('dir /s /b /a:d *.svn') do (
rd /s /q "%%i"
)
save it in a file del_All_Dot_SVN_Folders.cmd . Run it. Your done.
Thanks to http://www.axelscript.com/2008/03/11/delete-all-svn-files-in-windows/
Remember the above code has .svn whereas the code in the link has only *svn so its better
to have the .svn to not accidentally have undesired effect.