Hashing files

I want to be able to read the first 500 bytes off of a RAW file (or other files) and get the MD5 hash of them. Can someone provide me perhaps a snippet of code that can do this (or point me in the right direction)? I understand I have to use LrMD5 and probably some method to convert bytes to string so that LrMD5 can accept the argument.
Thanks! I am using/testing on both Lightroom 4/5 if that makes any difference.

Lua strings can hold binary data read from files, so really nothing tricky here, e.g.
local file = io.open( path, 'rb' )
local data = file:read( 500 )
local hash = LrMD5.digest( data )
io.close( file )
Untested, but should work, no?
Rob

Similar Messages

  • How to read und hash files!?

    Hi...
    I'm facing some "InputStream" problems.
    I want to hash files which is successful if files are < ~50MB. Here's my code...
    long length = file.length();
    InputStream in = new BufferedInputStream(new FileInputStream(file));
                   byte[] message = new byte[(int)length];
                    int offset = 0;
                      int numRead = 0;
                      while (offset < message.length
                             && (numRead=in.read(message, offset, message.length-offset)) >= 0)
                          offset += numRead;
    MessageDigest md = MessageDigest.getInstance("MD5");
    hash = md.digest(message);
    * toHexString
    **When I choose a file which is larger than 50 MB I get the following error:
    Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
    I know what that error means and what could solve this but not how.

    Have a look at the class java.security.DigestInputStream.

  • Error trying to Postmap a Hash file

    I'm following the instructions (at least I'm trying to) in "FrontlineSpam_Defense_for_Mail_in_Mac_OSX.pdf" to restrict the
    faking of my IP or domain names.
    I added these lines to main.cf :
    smtpdhelorequired = yes
    smtpdhelorestrictions = permitsaslauthenticated, permit_mynetworks,
    checkheloaccess hash:/etc/postfix/helo_access, rejectnon_fqdnhostname,
    rejectinvalidhostname, permit
    Then I created the file /etc/postfix/helo_access and added these contents
    to the helo_access file:
    xxx.yyy.zzz.xxx REJECT You are not me.
    mydomain.com REJECT You are not me.
    (with extra lines for my additional domains)
    The problem is when I attempt to "postmap" the Hash file.
    I type the commmand "sudo postmap /etc/postfix/helo_access" and I get:
    myserver:~ root# sudo postmap /etc/postfix/helo_access
    postmap: fatal: /etc/postfix/main.cf, line 659: missing '=' after attribute name: "checkheloaccess hash:/etc/postfix/helo_access, rejectnon_fqdnhostname, "
    Can anyone tell what I'm doing wrong?
    Thanks!
    Keith

    checkheloaccess hash:/etc/postfix/helo_access should be on the same line as smtpdhelorestrictions
    smtpdhelorestrictions = permitsaslauthenticated, permit_mynetworks, checkheloaccess hash:/etc/postfix/helo_access, rejectnon_fqdnhostname, rejectinvalidhostname, permit
    (above is one long line)
    Message was edited by: pterobyte

  • Berkeley DB MD5 Hash file

    Hi,
    I have a question regarding HASH file for Berkeley DB. How can I get the MD5 HASH file to make sure the tar file that I downloaded came from Oracle? Basically I am looking for how to validate that this software came from the Oracle site? Can you please help?
    Thank you.

    Hello,
    A while ago, maybe 4 years or so now, we used to build a MD5 file for every release download package. If you downloaded http://download.oracle.com/berkeley-db/db-5.0.21.tar.gz you could expect to find http://download.oracle.com/berkeley-db/db-5.0.21.tar.gz.md5 with the signature. I guess back then it wasn't all that common to do that and not many people downloaded the signature file. So, somewhere along the line we dropped that. I've considered re-starting that practice. Why? Well, lets just say that you're not the first to ask for it. :) Are you building something that automates the download of BDB code, then verifies the package? Just curious...
    thanks for the request/question,
    -greg
    Product Manager, Oracle Berkeley DB

  • Calculating hash values for really big files

    I am using the following code to calculate the hash values of files
    public static String hash(File f, String algorithm)
                throws IOException, NoSuchAlgorithmException {
            if (!f.isFile()) {
                throw new IOException("Not a file");
            RandomAccessFile raf = new RandomAccessFile(f, "r");
            byte b[] = new byte[(int) raf.length()];
            raf.readFully(b);
            raf.close();
            MessageDigest messageDigest = MessageDigest.getInstance(algorithm);
            messageDigest.update(b);
            return toHexString(messageDigest.digest());
        }Now the problem is, for really big files, 100 MB or over, I get an OutOfMemoryError.
    I have used the -Xms and -Xms options to increase the JVM heap size, and untimately made it to work. However, I think this is lame and there is also a limit to the -Xmx option.
    Is there any other way I can calculate the hash values of these really big files?
    Thanks a lot in advance.

    why do u open the file the way u do ?
    why to u upload ALL the file AT ONCE into the memory ?
    i would do it like this:
    FileInputStream fis = new FileInputStream (f);
    int fileSize = f.available();
    byte buffer[] = new byte[1000];
    MessageDigest messageDigest = MessageDigest.getInstance(algorithm);
    for(int read = 0;read < fileSize;read +=1000;)
    if(fis.available() > 1000)
    fis.read(buffer, read, 1000);
    else if(fis.available() > 0)
    fis.read(buffer, read, fis.available());
    else
    break;
    messageDigest.update(b);
    fis.close();
    return toHexString(messageDigest.digest());

  • Reseting the Hashed Password after enabling Windows File Sharing

    Disclaimer: you'll need a good bit of knowledge about OS X, UNIX, and encryption to understand what I'm talking about.
    All right, so normally OS X hashes user passwords using a salted SHA1 encryption. It uses shadowing so that you can't obtain the actual hash value using "% nidump passwd".
    BUT, if you enable Windows File Sharing, all that changes. OS X re-hashes your password using the much less secure LANMAN encryption. This allows Windows machines to access your files. (LANMAN is what Windows used to encrypt passwords up through Windows ME. Later versions of Windows use NTLM instead, which is stronger.) This is why, the first time you enable Windows File Sharing, OS X warns you that enabling the feature will require your password to be stored in a less secure manner; it's downgrading the hash from SHA1 to LANMAN.
    My question is: I'm done sharing files with idiot Windows users - how do I force OS X to go back to storing my password using SHA1?
    Thanks guys.
    -Bryan

    Thanks biovizier. You're absolutely right, deleting the extra text after ";shadowHash;" and then reseting the password for the user's account does seem to force OS X to rehash the password using SHA1.
    Just in case someone else has this question in the future, here's how to verify that your password is hashed in SHA1:
    Log in as Root and open the /private/var/db/shadow/hash folder. You'll see files with long, weird names. You'll also see an XML file (with the extension *.state) for each of the files with long, weird names. The XML file contains several tags that tell OS X information about the hashed password - things like when it last logged on, when it was created, how many times login failed, etc.
    We're interested in the other files - the ones that don't end in ".state"
    To verify that SHA1 is being used, open the long, weird files in textedit. You should see something like this:
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000059G31HJ75BR54210P07Y57BC57094D643H78K8765L98C6X000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000
    There should be a few more zeros; I've cut some out here to save space.
    What should NOT exist, is the following:
    57Y083D243109VGR45Z4B65812R8M087H65HJ8OK95T89L8JHL9000000000
    000000000000000000000000000000000000000000000000000000000000
    0000000059G31HJ75BR54210P07Y57BC57094D643H78K8765L98C6X00000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000000000000000
    00000000000000000000000000000
    The second Hashed value does not start with zeros. This hash value is not SHA1. It is the less secure encryption method required for compatability with Windows.
    If your hash file opens with zeros, you're using SHA1. Otherwise, follow Biovizier's procedure: Open NetInfo, select the user account whose password needs to be changed back to SHA1, look at the "authentication_authority" value, make sure the value is set to ;ShadowHash; and that no additional text follows that string, then reset the affected account's password. You can then log back in as root and re-check the hash files using textedit and you should find that the hash file opens with solid zeros instead of letters and numbers.
    Do NOT manually edit the hash files in textedit. One of those files is the hash for the Root password. If you change that hash file, your root password will no longer work (because when you type MYPASSWORD, OS X will hash that string and find that the hashed value no longer matches the stored hash value in /private/var/db/shadow/hash and OS X will therefore reject your password as incorrect) and you will quickly find yourself locked out of your computer for good.
    And finally, just in case you have the computing power of the NSA and are thinking about running the hashes I've listed here: A) They aren't the right length; I've left some characters out and B) I randomly substituted different alphanumerics in for the ones in my real hashes with no rhyme or reason.
    Which brings me to another point: NEVER post your hashes online. Yes, it takes a TON of computing power to break them, but still, they're hidden away for a reason!
    Anyway, I hope this helps other security buffs out there.
    I'm going to make a suggestion to Apple that OS 10.5 be changed so that when you unclick "windows file sharing" the OS immediately rehashes your password in SHA1 again.
    -Bryan

  • Hash could not be matched for the downloded content. Original ContentHash = , Downloaded ContentHash

    <![LOG[Download done setting progress bar to 100]LOG]!><time="15:54:30.490-120" date="01-21-2013" component="InstallSoftware" context="" type="1" thread="2544"
    file="downloadcontent.cpp:1603">
    <![LOG[VerifyContentHash: Hash algorithm is 32780]LOG]!><time="15:54:30.490-120" date="01-21-2013" component="InstallSoftware" context="" type="1" thread="2544"
    file="downloadcontent.cpp:1726">
    <![LOG[Failed to open file c:\_smstasksequence\packages\cms00007\configmgr2012adminui-rtm-kb2717295-i386.msp with error [32].
    ]LOG]!><time="15:54:30.490-120" date="01-21-2013" component="InstallSoftware" context="" type="3" thread="2544" file="securityutil.cpp:478">
    <![LOG[HashFile - exclusive access check for the file failed.]LOG]!><time="15:54:30.490-120" date="01-21-2013" component="InstallSoftware" context=""
    type="3" thread="2544" file="hashdir.cpp:227">
    <![LOG[Failed to hash file, Win32 error = 4103]LOG]!><time="15:54:30.490-120" date="01-21-2013" component="InstallSoftware" context="" type="3"
    thread="2544" file="hashdir.cpp:631">
    <![LOG[Hash could not be matched for the downloded content. Original ContentHash = 0617F93A16E48E5E4AE958081967812D78AF06F608A1C39CD9DE85D97003AD01, Downloaded ContentHash = ]LOG]!><time="15:54:30.490-120"
    date="01-21-2013" component="InstallSoftware" context="" type="3" thread="2544" file="downloadcontent.cpp:1771">
    <![LOG[0L == TS::Utility::VerifyPackageHash(pszContentID, sDestination), HRESULT=80091007 (e:\nts_sccm_release\sms\framework\tscore\resolvesource.cpp,2900)]LOG]!><time="15:54:30.490-120" date="01-21-2013"
    component="InstallSoftware" context="" type="0" thread="2544" file="resolvesource.cpp:2900">
    <![LOG[DownloadContentAndVerifyHash(pszPackageID, L"SMSPackage", saHttpContentSources, saSMBContentSources, saMulticastContentSources, sDestination, dwFlags, L"", 0, dwPackageFlags, pszUserName, pszUserPassword
    ), HRESULT=80091007 (e:\nts_sccm_release\sms\framework\tscore\resolvesource.cpp,3007)]LOG]!><time="15:54:30.490-120" date="01-21-2013" component="InstallSoftware" context="" type="0" thread="2544"
    file="resolvesource.cpp:3007">
    i saw this links :
    http://social.technet.microsoft.com/forums/en-US/configmgrosd/thread/909ea31c-7bda-49e2-8b06-ed4fc9c3c48c/
    http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/4801408b-de60-488c-9d80-7a87134abbaf/
    http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/4942384c-161c-454f-b8da-bc2a24844602
    http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/a57bb130-f231-4ced-8ec9-2f645ef9e5f1
    http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/7146fa83-d00e-4fc1-924b-a829860e506a
    i did not try to do this  Antivirus Scan and Exclusion Recommendations (i relay don't see why i need this if all oder task finshing succesfuly
    http://blogs.technet.com/b/configurationmgr/archive/2010/11/30/configmgr-2007-antivirus-scan-and-exclusion-recommendations.aspx
    i redownload the file from the -kb2717295 and recreate the package , i run this image deployment on all kind of PC they all failed, here is the
    file : configmgr2012adminui-rtm-kb2717295-i386.msp
    i don't know why this file failed, i run this manual it work and this task is also a deployment on collection and it have 100% successes on 8 pc
    i wander what make it failed .

    This is what worked for me. I had to create a brand new package and push it out to the DP's. Then updated my Task Sequence with the new package. It worked perfectly for me. I hope this helps.

  • Formatting the encrypted hard drive or intalling OS again with PXE boot can change TPM owner password file?

    Hello,
    1) I realized that when MBAM bitlocker encryption start both Recovery key and TPM owner password file are send to MBAM server. If we change the computername of the notebook, we can find out Recovery key from MBAM server with the KeyID as we can read it from
    computer screen, but we can not find out TPM owner password file with the existing new computername information from MBAM server, so we have to know old names of all computers but it is impossible. So we have to do decryption and clearing TPM than we
    can again encrypted it with its new name. is it right?
    2) We will going to deploy mbam encryption to our notebooks. But sometimes when a person quit the job his notebook can given to another person or new employee and based to our procedure when a notebook will given to another user it should installed
    OS again with PXE boot. I would to know will it be enough to installing with this method again with a diffrent computer name or should I firstly clear its TPM than install OS with PXE to keep TPM owner password file missing as item 1?
    I hope i can explain what i mean :)
    Regards,
    SibelM

    I would suggest you to first decrypt the laptop and then follow the process:-
    - Clear the TPM
    - Encrypt the type.
    - Check for the encryption behavior.
    Cause I have found on some model that if the OS drive is encrypted, PXE boot fail on that machine even though I also did a direct PXE on an encrypted machine with clearing the TPM.
    TPM ownership password is a hash file that gets generated with a set of algorithm. SO each time when you PXE boot, by clearing the TPM, the TPM hash password for the TPM will change. This has been done for security measures.  
    Gaurav Ranjan

  • Mmap or malloc for 20GB file?

    Greetings,
    I have to process a flat file of about 17TB, and in the process I need to perform source to target lookup values which will be stored in a pre-processed hash file. The hash lookup table, for the 838 million or so records, will be approximately 20GB. Hardware is a SunFire (E25 or something) with about 8 CPU's allocated (SPARC), Solaris 10, 32GB RAM, and about 35TB of disk array. I will be compiling with the �xarch=v9b parameter for full 64-bit executables.
    The 17TB input file will be a sequential read, so even though it is big, it should not be a problem. What I am trying to determine is how best to access the hash lookup table? Since good hash functions have the quality that they disperse the keys evenly throughout the table, lookups will require random access to the entire range of the table for the duration of the run.
    What I am wondering is, would it be better to try and mmap the lookup table, or just malloc the 20GB at runtime and let the vm system handle it? Also, since the input file can be slit for processing, it would be advantageous to be able to run the program multiple times concurrently, each with its own chunk of the input. Thus, the lookup table would have to be accessed by the processes simultaneously as well (luckily as read only). Unfortunately, the lookup table cannot be split like the input data since any key could exist in any of the chunks.
    Any insight would be greatly appreciated.
    Thanks,
    Matthew

    If lookup table has to be shared among processes, then mmap with MAP_READ and
    MAP_SHARED is the choice.
    As I am writing this, I am wondering, how will it be, if I create a ISM segment using
    shmget/shmat and then keep reading the hash file into the address retuned by shmat
    from one process and then rest of the processes can just attach to that specific SHMID.
    This way even VM data structrues are shared among processes. But you need to try
    this out yourself to see how it works.
    -surya

  • Temp files eating up all disk space on SCSM 2012 R2 install

    Hello Everyone,
    Problem
    Under this path SCSM is creating a ton of temp files using up all disk space (C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\System Center Service Manager 2010)  All files are .bin and .hash files.  I just cleaned out 120 GBs
    of files which accumulated over the period of 30 days.   
    Does anyone know what could be causing this?  This was not a problem when we were on server 2008 R2.  When we migrated SCSM management server to server 2012 r2 it when problem started.
    Environment
    Management server (server 2012 R2)
    Data warehouse server (server 2008 R2)
    Data on remote SQL server.  SQL 2008 R2
    CU  5 was the last update

    Might be worth checking that the AutoRefresh/Cache policy is set to True via the SDK?
    https://msdn.microsoft.com/en-us/library/gg461136.aspx
    From PowerShell:
    Add-Type -Path "C:\Program Files\Microsoft System Center 2012 R2\Service Manager\SDK Binaries\Microsoft.EnterpriseManagement.Core.dll"
    $NS = "Microsoft.EnterpriseManagement"
    $EMGType = "$NS.EnterpriseManagementGroup"
    $EMG = new-object $EMGType localhost
    $EMG.AutoRefreshCache
    Output True or False
    $EMG.CacheMode
    Configuration
    This is the output from mine:
    Good luck!

  • Default Apache dbm file type under Portal??

    hi,
    I'm trying to find out how Apache was compiled in the default Portal 9.0.2.6 install. In particular, I'm trying to use a hash file in combination with a RewriteMap for mod_rewrite use, but I need to know what type of HashFile Apache was compiled to be able to use.
    Does anybody know the default type of db file Apache under Portal expects, or where I might find this information documented?
    thanks....

    Just for closure this issue has been resolved now. I did not change my PC, just reverted back to using XP for a while. Tried again on Win7 recently and the vids play back perfectly fine. Update from windows rather than adobe may have fixed it as Idid not recall an adobe update being installed.

  • Deploying DC: warning in opening zip file

    Hi,
    I got this warning from Dev studio DC build on 04s SP08:
    packDeployArchive:
    [srcpacker] Creating source archive
    [srcpacker] Adding source archive from xxxxxxxx
    [srcpacker] WARNING: Could not open ZIP file C:\Documents and Settings\xxxxx\.dtc\LocalDevelopment\t\21FBE3BC3185FEB251FDBE23923FAB55\wda-pp\src\java\src.zip.HASH : error in opening zip file
    It's pointing to a HASH file not a zip file. The zip file 'src.zip' opens fine if I open it with explorer. I haven't tried if the hash is actually correct for the file or not.
    What does this mean then ? Should I care about it ?
    Jari

    Jari,
         I encounter the same problem. Have you got a solution yet?
    Helen

  • Fileupload issue. Unable to get the full local directory path of the file uploaded

    Fileupload Applet Issue with Firefox 15:
    When uploading a file using our application, file that is being uploaded is hashed using a signed Applet.
    This is working fine in IE and FF version lower than FF15.
    Signed applet needs to hash file contents but it is is unable to read the full path of the uploaded file, and thus failing.
    Applet expects the full path of the file that has been uploaded
    Is there any way to get the full file path?

    Is not a new feature and not really a bug, but rather a security change that they have cleaned up code and removed the ability to use UniversalXPConnect that made it possible in older Firefox versions to get enhanced privileges.<br />
    That is no longer possible, so any code that relies on it will fail silently.<br />
    You will now require an extension to run any code that requires enhanced XPCOM permissions.

  • How direct md5 to check files on optical disc

    Hello,
    I've got several optical discs (bd-r) for which I have an md5 of the entire disc's contents. But the md5 file is on hard drive (not onboard the optical disc) and I can't seem to figure out how to direct the md5 to compare hashes with files on the optical disc (or any mounted volume for that matter). I've tried editing the md5 line(s) to read:
    6670882691e48719b377e09a6b7c1303  /mnt/[name of disc or volume]/[name of file]
    and tried:
    6670882691e48719b377e09a6b7c1303  /volumes/[name of disc or volume]/[name of file]
    and so on....with and without leading slashes...
    ...no luck so far.
    Is it possible to get an md5 to access a mounted volume/optical disc?
    Thanks in advance

    Thanks Bob,
    Yes, I'm using the saved md5 (and adding "/volumes/[name of disc]/....." to each line, to compare to the currently mounted media.
    I'll try in some different apps, per your suggestion that it may be inherent to CHECKSUM+ app.
    Your concept of using the "md5 unix command line utility" to generate from the disc and then compare to original md5 could work. Is this utility already part of the OS? and can it generate hashes for entire directory with subfolders? (doing one file at a time would not be feasible).
    I tried dropping the optical disc into CHECKSUM+ to generate another hash page (with the intent to compare it to the original hash sheet using KDIFF), but it gave an error - didn't like the concept, I guess of generating hashes for a read-only volume? or didn't know where to drop the resulting hash file?
    Thanks in advance
    Sam

  • User Login(s) / Account gone - BUG - thread overview - summary - solutions?

    Hello everyone...
    Time to open a new thread... Seems there is a serious bug going on since a while with 10.6 randomly, hit me saturday. After working late switched off my iMac and next morning all my user accounts were gone, not able to login with my account... instead I got a "other" account.
    Took me a day to get that fixed. Thanks Apple!
    Same problems here:
    http://discussions.apple.com/thread.jspa?threadID=2750969&tstart=0
    http://discussions.apple.com/thread.jspa?messageID=13050110&#13050110
    http://discussions.apple.com/thread.jspa?threadID=2747165&tstart=0
    http://discussions.apple.com/thread.jspa?messageID=12880505&#12880505
    http://discussions.apple.com/thread.jspa?messageID=12932314&#12932314
    http://discussions.apple.com/thread.jspa?messageID=12754295&#12754295
    http://discussions.apple.com/thread.jspa?messageID=12802769&#12802769
    http://discussions.apple.com/thread.jspa?messageID=12640182&#12640182
    http://discussions.apple.com/thread.jspa?messageID=12836318&#12836318
    http://discussions.apple.com/thread.jspa?messageID=12840608&#12840608
    http://discussions.apple.com/thread.jspa?messageID=12726662&#12726662
    This one has a interesting solution from user Illude
    http://discussions.apple.com/thread.jspa?threadID=2644133&tstart=0
    This one's from cNet:
    http://forums.cnet.com/7723-6126_102-505918.html
    There are quite some possible solutions (from threads) that seem to help, here are some of the popular ones:
    SOLUTION 1:
    1 - boot up using your SL disk.
    2 - select 'change password'
    3 - reset the root password
    4 - restart the mac from the system drive
    5 - log in as root
    6 - open system preferences
    7 - create an account with the SAME FULL NAME and ACCOUNT NAME as your 'lost' account
    8 - you will be prompted that "a folder with said name already exists - would you like to use the existing folder?" - SELECT OK
    9 - log out of root
    10- log into your account
    SOLUTION 2 for those without TM backup:
    Material needed: Snow Leopard DVD
    1. Boot from DVD: restart at log in menu you're stuck in. Otherwise hard restart. Press "C" while booting.
    2. Change password: in my case only System Administrator (root) and guest appeared. Change the password on System administrator.
    3. log in as "System Administrator" with your new password.
    4. Check to see if the folder with your user name is still there under "User"
    5. Go to System Preference>Account>add account: Set same account name. That will link the new user account with old username account folder. You can also adjust the login window option. For now I checked automatic log in.
    6. Restart. You should be able to log in to your old account.
    SOLUTION 3 with TERMINAL (from illude - thanks!):
    ... I had this exact problem. I installed the 10.6.5 update and when I finally rebooted several days later, all non-system users on my machine were deleted. Only "Other" showed up in the login screen. While the users were removed from the Directory Services, their data was still intact though, as their home directories in /Users were unchanged. This is of course a big relief...
    After reading this thread and the pages mentioned here, I came up with the following solution. Please replace "username" with the short (Unix) name of your user account (i.e. the one without spaces).
    1. Start the computer in Single-User Mode, by holding down Command+S as it boots up. You end up in a terminal as the root user.
    2. As suggested on the screen, do the following to check and mount your filesystem:
    /sbin/fsck -fy
    /sbin/mount -uw /
    3. Find out which accounts have been deleted (here I assume 'username' is one of them):
    defaults read /Library/Preferences/com.apple.preferences.accounts
    4. Convince yourself that the user data is still safe:
    ls /Users/username
    5. I noticed that the 10.6.5 update made backups of the Directory Services and shadow passwords in /private/var/db as the xar archives 'dslocal-backup.xar' and 'shadow-backup.xar', respectively. If you also have these files, you are in luck! Restore the settings for each deleted user, as well as all shadow passwords, as follows:
    cd /private/var/db
    xar -xf dslocal-backup.xar dslocal/nodes/Default/users/username.plist
    xar -xf shadow-backup.xar
    6. For good measure, remove the record of deleted users (not sure if this is necessary, but seemed like a good idea at the time):
    rm /Library/Preferences/com.apple.preferences.accounts.plist
    7. Restart the computer:
    shutdown -r now
    I restored the settings for all deleted users in Step 5, and everyone was back after the reboot. The great thing is that all settings are restored the way they were, including the password, user GUID (which should prevent Time Machine from redoing a full backup as mentioned in this thread) and the login picture (which was stored in the JPEGPhoto field in the plist file and would have been lost otherwise).
    Of course, this solution might not apply to your specific problem, so please take care when you tamper with system settings via Single-User Mode.
    SOLUTION 4 using a TimeMachine Backup:
    If you have a backup with time machine, reinstall with original OSX DVD.
    For that type "C" when booting and hold until system boots from DVD.
    Go trough necessary steps, then when asked if you want to restore from a TimeMachine Backup, do so. Will take some hours depending on how big your TM backup is and what kind of interface you use (GBit Network, USB, Firewire etc).
    After that your system should be restored. However you proably have to update back again to the latest OSX update you were using with that TM backup, as OSX Mail will crash if it doesn't have that exact update environment. Example: your TM backup was done with 10.6.6., mail will crash often if you restore to 10.6.5...
    ATTENTION: there may be some side effects after a restore regarding external volumes, they could be locked out as your old user settings are gone...
    After restore I could not access two external drives on my system,
    1) a firewire 2TB Lacie drive that was "locked". I did not have the rights to access it, and CTRL+I and setting the permissions did not work. permissions were not stored. The OSX Harddisk tool also did not work because the "owner" of that drive could not be set.
    Solution: A tiny app called "BatChmod" saved the day, it allowed me "unlock" the permissions of that drive, without being a Unix superfreak knowing all the tweaks.
    http://www.macchampion.com/arbysoft/BatchMod/Download.html
    2) I could not access my TimeCapsule TM after restore to refresh the backup. Quite interesting because my system just had restored from that drive. The TimeMachine Volume was locked with that little "lock" symbol left of the volume symbol. CTRL+I and setting permissions did not work too... Within OSX Harddisk Tool a TimeCapsule does not show up so you can't fix permissions there either...
    Solution: With Airports TimeCapsule Manual Settings there is a option to delete the volume or folders on it. deleted the sparsebundle and voila the TC could be used again.
    If there are any other solutions that worked out for you to recover from lost logins/accounts, please post them here, and do not forget to notify apple about that bug at
    http://www.apple.com/feedback/macosx.html
    so that it hopefully finally get's fixed with 10.6.7... it seems to be around since 10.5..., emerged again with 10.6 SL, and now came back with 10.6.6. so that should have been quite a long time to fix it.
    Thx
    Chris
    Message was edited by: vertrider
    Message was edited by: vertrider

    this symptom caught me by surprise just the other day - luckily I had the root account enabled, which is not the default.  With the root account enabled, and an available Time Machine backup, recovery is really simple, straightforward and quick.
    For my situation, which may not be identical with those for all who may read this thread, the plist files which define for DirectoryService the users I have created, including my admin accounts, and the password hash files were deleted.
    if the root account is not enabled on your system, then I suppose you will have to go through either booting in Single User mode or from a System Install disk that will let you run the Terminal application.  However it is done, once you have the ability to write to the database directories, and access to a Time Machine backup, the recovery process is thus:
    Step 1. Verify that the user account home directories still exist, both for peace of mind and to determine whether this recovery method is appropriate for your situation.
    ls -l /Users/
    This should show account directories for all the users you have created in the past.  If not, then a restore of the user directories from a Time Machine backup, as well as the user DirectoryService files is indicated.  And, I would propose that the cause of your particular difficulties is other than most in this thread have experienced.
    also, just for fun, open the Accounts Preference Pane in the System Preferences, and see that none of your user accounts are listed.  What I found interesting is that the groups that I had created were still defined, it was just the user accounts that were deleted.
    Step 2.  now, for the meat of the recovery.  I recommend opening a pair of Terminal windows, one in which to look at the database directories, the other to look at the Time machine directories.
    in the "database" window, change directory to the user accounts area.  This is read-write-execute for root only, so if you are not able to cd to this directory, you'll need to wrap the commands in sudo.
    cd  /var/db/dslocal/nodes/Default/users/
    ls -l
    [non-root version of commands:  cd /var/db/dslocal/nodes/;  sudo ls -l Default/users/ ]
    the result should show a number of plist files, with many system users starting with an underscore, and only a few others:  daemon.plist, nobody.plist, root.plist
    Step 3. in  the "TimeMachine" window, change directory to the user accounts area from a recent backup, such as this one for my computer "Odin", backed up to TimeMachineDrive (this is a long path, not a two line entry):
    cd /Volumes/TimeMachineDrive/Backups.backupdb/Odin/2011-04-20-002126/Odin/var/db/d slocal/nodes/Default/users/
    then perform a directory listing:
    ls -l
    [non-root version of command is similar to that in Step 2, only need to get to the dslocal/nodes/ directory on the TimeMachine volume]
    you should see all the same plist files as in Step 2, along with the additional user accounts definitions for those accounts you originally created.
    to restore the definitions to your system, copy the missing plist files to the database directory used in Step 2. For a missing account file "test.plist", this would be:
    cp -X test.plist /var/db/dslocal/nodes/Default/users/
    [non-root version of command:  sudo cp -X Default/users/test.plist /var/db/dslocal/nodes/Default/users/ ]
    the command option "-X" keeps the extended attributes from being copied along with the file
    do the same for each missing plist file.
    Step 4. this step restarts DirectoryService, so it becomes aware of newly restored account definitions.
    killall HUP DirectoryService
    [non-root version:  sudo killall HUP DirectoryService ]
    note:  DirectoryService will recognize the new accounts after a reboot, even without the killall command being issued.  I just like to avoid unnecessary rebooting....
    now comes the fun part - open up the Accounts Preference Pane in the System Preferences, or close and reopen if already open, and voila, the missing accounts should all be shown again!  If you perform a listing of the /Users directory, you'll see the account names instead of UID numbers shown as owner of the account directories once again.
    ls -l /Users/
    Great!  ready to go, right?  Almost, but we have to fix the ability to log in for these accounts first, by restoring the shadow password hash files.
    Step 5. to restore the hash files, we need to know which ones belong to which account, and which directories to restore from and to.  So, in the 'database' window
    cd /var/db/shadow/hash/
    ls -l
    [non-root version:  cd /var/db/;  sudo ls -l shadow/hash/ ]
    in the "TimeMachine" window, assuming you are still in the var/db/dslocal/nodes/Default/users/ directory:
    cd ../../../shadow/hash/
    ls -l
    [non-root version, assumes you are in the var/db/ directory:  sudo ls -l shadow/hash/ ]
    you should see a bunch of files with filenames consisting of uppercase letters, numbers, and dashes.  To determine which file(s) belongs to which account, here is an example for the account "test":
    dscl . -read /Users/test GeneratedUID
    [non-root version:  same as root version of command ]
    result should look like:
    GeneratedUID: E7FBADC6-CFCB-4B31-88F9-BB6BD1FAEB52
    this long string identifies which hash file(s) belongs with the account "test"
    from the "TimeMachine" window, copy the hash file back to the system location:
    cp -X E7FBADC6-CFCB-4B31-88F9-BB6BD1FAEB52* /var/db/shadow/hash/
    [non-root version, all on one line: sudo cp -X shadow/hash/E7FBADC6-CFCB-4B31-88F9-BB6BD1FAEB52* /var/db/shadow/hash/ ]
    once this is completed for all the missing accounts, your system should be restored to exactly the condition it was in prior to the user accounts disappearing.
    in Solution 3 above, from illude, the file  /Library/Preferences/com.apple.preferences.accounts.plist is mentioned.  I believe this is a file that was generated in Mac OS X 10.4, and maybe 10.5.  I'm pretty sure that a clean fresh install of Mac OS X 10.6, on a new partition for example, will *not* have this file.  Therefore, it a) may not be present, and b) if present, may have contents that don't represent any accounts created since the installation of Snow Leopard on that machine.
    be that all as it may - I wish I'd found this thread topic when this first occurred for me. But since I managed a solution, I thought I'd share, in case anyone finds these methods useful.
    cheers,
    Roy

Maybe you are looking for