#1063 Unable to create intermediate backup in Password Safe 3.29

path (1)

I believe I've found the cause to this problem in version 3.29. I'm not sure if the problem carried over from previous versions (i.e. 3.26) but I've done some thorough testing of version 3.29 to figure out why I was getting the 'Unable to create intermediate backup' error.

As you'll see in my attached PDF, I believe what is happening is that the OPEN FILE/CLOSE FILE programming code isn't taking into consideration the directory within the path of the psafe3 file that is opened. The OPEN FILE program code is not as picky as the CLOSE FILE code since the file actually opens. However, when the CLOSE FILE command is issued, it errors out because it cannot locate the actual path of the original file as it appears it was not captured upon opening the file.

I hope my research helps to plug this hole and resolves the problem for good. :)

1 Attachments


  • Matt

    Matt - 2012-10-04

    sorry, forgot to mention my OS environment...

    I'm running on Win7Ent-SP1

  • Matt

    Matt - 2012-10-04

    By the way, I know it has been suggested numerous times by DrK as well as Rony Shapiro that it is a permissions issue. I've confirmed that with my case it is not a permissions issue as I am the owner of the directories as well as have 'full control' of the directory and all of its contents.

  • Matt

    Matt - 2012-10-04

    In the PDF I've attached, on page 2, there's an observation I made where there are two periods (.) listed in the popup dialog. I've looked through the source code, and found that the two periods are a cause of having two periods in the original msg + the referring message in the pwsafe.pot file, line 426.

    In line 426 it says, "msgid "%s. Either try to save database with another name or exit without saving." %s is referencing line 6215 which already contains a period. This would be why we see two periods.

    Just thought I'd bring it to light since my observation is a non-issue here.

  • Tim Collins

    Tim Collins - 2012-10-04


    What type of drive is Z:? I'll bet it is a shared drive of some sort.

    I have experienced the same frustrations with "Unable to create intermediate backup" error, but have determined it is related to my OS/setup.

    Facts for my situation:
    - Windows 7 Professional SP1
    - VMware Workstation 8.0.4
    - 3.26, 3.27, 3.28, 3.29 all experienced this "Unable ... backup" error
    - using 3.27 due to multi-entry highlight bug in v3.28/29 when typing entry names in list view mode (see: https://sourceforge.net/p/passwordsafe/bugs/1030/)
    - Password safe is installed on my host (Win7) machine as well as each of my VMs (one for each customer to whom I provide services)
    - My Password Safe DB is installed at C:\Users\Tim\Documents\My Safes\pwsafe.psafe3
    - If only from my host machine (i.e. local drive C:), I can open, run, modify, save, etc. without issues as long as that is the only place I am accessing the DB.
    - I DO HAVE PROBLEMS when I access the DB in READ-ONLY mode from a VM
    - On my VMs I setup shared folder (Z: drive) as READ-ONLY to access the host folder holding my PW safe file.
    - Prior to Win7 I ran WinXP with WMware WS 7 (or maybe 6 - can't remember) and never received the "Unable to create intermediate backup" error. I could add entries via the host machine, my VMs could not change the DB since the "share" is READ-ONLY. VMs had simultaneous access to the DB and all was well.
    - When running PWS from a VM it knows the share is READ-ONLY and treats the DB as READ-ONLY and no changes are allowed.
    - On XP, the host never detected any other access (it was all R/O).
    - After upgrading to Win 7 and/or VM 7/8 the problem started to happen. The host machine was generating the "Unable to create intermediate backup" error and I could not save any changes. PWS on the VM still detects the access as R/O, but for some reason the host machine does not think it has exclusive access to the DB, thus the errors.
    - My work around, I copy the DB (never optimal) to C:\Users\Tim\Documents\Virtual Machines\PWSafe Copy\pwsafe.psafe3, access that mount from my VMs, removed the mount to C:\Users\Tim\Documents\My Safes\pwsafe.psafe3 and now have no problems

    I conclude, that either VMware or Win7 doesn't honor the RO mounts the way it should from the perspective of C:\Users\Tim\Documents\My Safes\pwsafe.psafe3. <-- thinks another process is accessing either the DB or the directory and cannot create the intermediate backups it wants.

    Matt, try this:
    - Move your pwsafe.psafe3 file to a local disk and I'll bet you have no more problems.
    - I understand it is not optimal because you won't get your automatic backups (or other benefits of being on your Z:\ drive), and it is the same for me - I dislike having to copy the DB after changes are made so my VMs get access to the updated version, but ...

    I have not pursued it further - just have not found the time.

    Rony, et al.
    - Any ideas/suggestions on a resolution for me based upon the information I shared?

    Last edit: Rony Shapiro 2012-10-05
  • Tim Collins

    Tim Collins - 2012-10-04

    Just saw my post - sorry about my not noticing that back slashes ("\") are interpreted as a meta character and disappear.


    C:UsersTimDocumentsMy Safespwsafe.psafe3

    should be

    C:\Users\Tim\Documents\My Safes\pwsafe.psafe3

  • Matt

    Matt - 2012-10-04

    I figured the back slashes were being parsed out, so no worries.

    I'm running this on a laptop, from a network shared mapped drive. No VM is involved.

    I'm using it at work, and our windows management team has locked down our systems so tight that we're unable to do much, but I was able to copy the files to "c:\users\public\pwsafe" and run it from there and my results are still the same as described in the PDF. If I only type the command: "pwsafe a.psafe3" and make an edit, I still get the error. I then open pwsafe without passing the safe file and it shows the path of the file as "C:a.psafe3". So it doesn't matter where the file is located within my particular environment, I get the same results.

    Last edit: Matt 2012-10-04
  • Matt

    Matt - 2012-10-04

    Ok, being a majorly novice programmer (only done enough to get through school), I've been looking through the source code at what appears to be the most logical locations, and I came across a line of code that I'm wondering if is written correctly. Please note, I'm not trying to be condescending in any way by pointing out possible errors, I just want to help if I can.

    So here's some things I'm noticing and once again being a novice, I don't know if they are an issue or not, but I'll mention them and you can /smack me if you notice they ARE a non-issue.

    src > core > PWSdirs.h > line 39 I notice that execdir doesn't contain the parentheses (). Not sure if it needs it.

    src > os > windows > dir.cpp > line 42 states "charT *curdir = ...". I'm not sure if the asterisk before curdir is needed. I'm trying to find another example of this to see if this is acceptable syntax. I know normally this is used for commenting so I'm curious if CPP is panicking over this. According to this site and asterisk can be used as a difference operator, but it comes after the equals sign.

    Edit: Ok, I see the asterisk is being used as a pointer initialization on the aforementioned site. So syntactically it is correct if it's being used this way, which that part I don't know.

    Just a reminder, the problem I'm getting is that the program is not getting my current working directory (getcwd), it's only getting the drive and the file name correctly. That's why I'm looking where I am.

    I could be way off in my observations, so please go easy on me. I would love to know how to code better than what I know now, but I haven't had a reason to do any coding up to this point, thus the rustiness of my coding knowledge.

    If this isn't anything, please let me know and I'll keep reading the code. Maybe I'll learn the code again/better using this as a stepping point in the right direction.

    Last edit: Matt 2012-10-04
    • Rony Shapiro

      Rony Shapiro - 2012-10-05

      Hi Matt,

      Thanks for taking the time to dive into this. I've just started looking at this thread, and am replying to this first because the answer's straightforward:
      1. execdir doesn't need paren's, as it's a variable declaration. Paren's signify a function declaration.
      2. charT *curdir = _tgetcwd(NULL, 512); means that curdir is a variable of type 'pointer to charT' with an initial value of whatever's returned by _tgetcwd(...).

      In general, looking for syntactic errors is sort of barking up the wrong tree, as that's what the compiler's there to catch. The problem here's semantic, which is more subtle, and irreproducible on my machine, which is why it's still out there. Now to start looking into it in earnest.

  • Rony Shapiro

    Rony Shapiro - 2012-10-05

    OK, I think I fixed this. What I did was to 'normalize' the file name passed in the command line so that it's always converted into an absolute path.
    You can find a version with this fix in
    Please let me know if the fix works for you.



    P.S. I also fixed the '..' typo - nice catch!

  • Rony Shapiro

    Rony Shapiro - 2012-10-05
    • status: open --> pending
    • assigned_to: Rony Shapiro
  • Matt

    Matt - 2012-10-05

    Hi Rony,
    I'm in the middle testing now, but could I possibly ask for the md5 hash for this just to ensure I'm getting a 1-for-1 copy of the file please, if it's not too much to ask. I want to make sure my dl didn't get screwed up in mid-flight as well (not that it has anyway). It would be a disservice if I'm testing something that isn't 100% what you intended.


    • Rony Shapiro

      Rony Shapiro - 2012-10-05

      The md5 sum of the zip file I uploaded is 50599944db0d72faf0a204b21b7e3d0c

  • Matt

    Matt - 2012-10-05

    Ok, I went ahead and did my testing because I was anxious to see the results, and from the stand point of my findings, the changes have made it bulletproof. :) I now no longer get the error, and every attempt to reproduce the problem couldn't be done. Now when I open pwsafe with the file name (only), or using a relative path, it puts the full path in the 'Open Password Database' field. Perfect!

    So I believe you've fixed the problem for a lot of people based on the multiple entries I've seen posted in the support request page.

    Out of curiosity, do you know if this problem persisted throughout the earlier versions? The reason I ask is because I did see a lot of people getting the same error with multiple earlier versions.

    Thanks so much Rony for your help with this. Love to see developers that are uber responsive like this. It goes along way to building great street cred.

    I will be posting a very positive review on this software in the near future.

    (p.s. Would you mind shooting me an email describing where you made the changes to the code? I would really like to see how you did it as I'm interested in learning to code more effectively. Even if you just tell me the files you changed, I can look for the differences. If you are too busy or can't be bothered to do so, no worries, just thought I'd ask.)

    Last edit: Matt 2012-10-05
  • Rony Shapiro

    Rony Shapiro - 2012-10-05

    Glad to see the fix works for you.
    I have to admit - without your help in reporting this in such detail, I would never have nailed it down.
    The change I made was trivial, just called a function to 'normalize' the filename to an absolute path. Unfortunately, there's an issue with SourceForge's repository right now, so I can't point you to the exact change, but the main file changed is src/ui/Windows/ThisMfcApp.cpp, in the command-line argument parsing.
    As this code's pretty old, I think we can safely assume that you've nailed this problem for all the related tickets, which I'll be updating later.
    Again, thanks for putting in time to track this down.


  • Rony Shapiro

    Rony Shapiro - 2012-10-06
    • status: open --> closed
  • Rony Shapiro

    Rony Shapiro - 2015-10-14
    • status: pending --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks