After the Open Directory crashed several times on a osx server 10.9 I decided to start from scratch; formatting the disk, installing osx 10.9 and setting up server.app as it was before.
To recover the mails I though being smart and copying the contents of the mailbox per user (Location /Library/Server/Mail/Data/mail/[OLD GUID]) to the fresh setup.
Logging in showed everything in the inbox. Now, few days later I find out that the sent folder is empty, or doenst contain any mails before the install. Turns out that only the inbox is copied.
Does someone has any suggestions how I can get back the sent items?
After some more research I solved my question; I hope that this helps my fellow colleagues in saving time and nightmares.
(Sub)Folders in dovecot have their own directory, starting with a dot (.), for example .Sent Messages. Because of that dot the folder is hidden. I copied the subfolders to the new mail directory, updated the correct user permissions and was able to get the old messages back.
If the user (or client software) already has added the same folder, simply rename it. Another possibility is to add a temporary user, restore the e-mails to that one. On the users mail client you add this temporary mailbox and move the messages to the correct folder. This last solution only works good when there are not too much messages.
What really helped me as well was connecting IMAP via the terminal using openssl, an easy guide can be found here.
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 am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
The recommended solution is for your installer to create a sub
directory of C:\ProgramData for your shared storage. And that sub
directory must be given a permissive ACL by the installation program.
That is what grants the desired access to all standard users.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.
I am working with espresso for Mac, and I've found that I may have a problem with publishing tools.
My server is located at the USA, but I, and my computer, are located in Spain. So when I modify a file in my computer, and then one of my partners edits it again in the USA, if I do a sync, I erase his file with mine ... even being mine older.
I think that this is happening because my TIMESTAMP is in GMT+1, while server and partners time is GMT-8 (California), so their file will only be newer than mine if they touch it 9 hours later.
How can I fix that??
Thanks in advance!!
In Espresso 1, go to the server's preferences and expand advanced settings (could be named something different, I'm working from memory). There should be a button to detect the time difference between your computer and the server. Use that and you should be good to go. I think Espresso 2 does this automatically now.
If you continue to have issues, send a message to support#rhinointernet.com. They like to take care of FTP issues over email.
So I did something really stupid... I got a new MBP, and gave my old one to a friend. Before I did that, I transferred all of the contents of my big folders (Documents, Downloads, etc...) to my new Mac, and then I deleted the user on my old Mac. Unfortunately, I neglected to transfer the folder that contained the entire Xcode Project for my app that is currently on the App Store, as it wasn't in one of those folders, and I'm the only one who had it. The only way of being able to retrieve it that I thought of was that since I had to upload the binary to iTunes Connect to submit the app, Apple might still have it. Otherwise, I guess I'll have to completely start from scratch if I ever want to update it again. I just contacted Apple via iTunes Connect, but I was wondering if anyone has any idea of what I am able to do now, mainly, if Apple will actually give me all the files back. Thanks.
Any chance you've got a backup via timemachine?
Timemachine can't help you in the case of a fire (see http://github.com for what you can do about fires, hurricanes, tornadoes, volcanoes, or thieves), but maybe it can save your bacon right now. :)
Yeah, you pretty much lost it. I'd recommend looking at some source control - for example Github. It's built into XCode, and Github is pretty cheap for Private Repositories, and free for public ones.
You (nor Apple) won't be able to retrieve it from the binary.
No revision control system?!
You wiped your data or only simply deleted?
Because, here is a possibility retrieve data from the HDD (or at least some parts) when only simply deleted them. Delete usually does not wipe the data.
If you can get your old HDD, you should:
- insert it into external usb-HDD enclosure
- attach to your new MAC
- make an image from it to one big file (with the command "dd") (assuming than your new HDD is bigger than your old)
- and with several tools you can "try" recover some data
every use of the old HDD drastically lowering the chance recovering something from it.
I bought my own application from the Mac AppStore. The app was not saved in the Applications folder, but instead in /Users/nathan/Library/Developer/Xcode/Archives/2011-06-14/Release PackageTracking 6-14-11 12.09 PM.xcarchive/Products/Users/nathan
Is it just for me because I am the developer? Or are all my users going to have to hunt down that file? Why didn't it download it to the correct location?
You have to find and delete (or hide) absolutely every copy of your application (all debug copies, archive copies, anything with the same bundle ID) from your system before doing a test purchase.
You can try using Spotlight to find apps.
One way to hide apps is to compress them using gzip. Or move them to a disk drive that can be unmounted.
Users with no previous copies of your app won't have this problem. Users who have previous copies of your app and who put these copies in strange places might encounter this problem.
I would hazard a guess that it is because you already had a version of the app in that location from when you built it using the Archive option in Xcode.
The App Store would have detected that it has the same bundle ID and updated it in-place.