Announcement

Collapse
No announcement yet.

svn export failing using file schema under v1.10

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • svn export failing using file schema under v1.10

    Hi,

    Today I noticed that the exports performed as part of a regular back-up are now failing following the upgrade from v1.9.7-2 to v1.10.0-1 performed on 2018-04-24

    The details:

    Platform: Cygwin 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin

    Repository: Typical example:
    Path: /var/repos/svn/<repos_name>
    UUID: 80441a15-f459-49e5-accb-cdeddae00d91
    Revisions: 2336
    Repository Format: 5
    Compatible With Version: 1.8.0
    Repository Capability: mergeinfo
    Filesystem Type: fsfs
    Filesystem Format: 6
    FSFS Sharded: yes
    FSFS Shard Size: 1000
    FSFS Shards Packed: 0/2
    FSFS Logical Addressing: no
    Configuration File: /var/repos/svn/<repos-name>/db/fsfs.conf

    svn, version 1.10.0 (r1827917)
    compiled Apr 22 2018, 17:20:30 on x86_64-unknown-cygwin


    The backup is performed as an export of each repository. The export is performed on the server to a local path for replication of the export elsewhere.

    The export jobs have run without error for a number of years working through a number of upgrades of subversion without issue.

    The last successful export was the last one before the upgrade, first failure is for the first export after the upgrade.


    M.O.

    Export task starts, and creates the target folder, but fails when setting the permission on the first file with an error of the form:

    svn: E000002: Can't set permissions on <full-file-path>
    svn: E000002: Can't set permissions on <full-file-path>: No such file or directory


    The named file does not appear in the folder, but two two working temp files are present in the form:

    svn-XXXXXX

    Both of these files are a copy of <full-file-path>, one of which does not have the data in the $Id: field.

    The permissions on the folders are no different from previous exports, and writes take place anyway.

    Update: The export creates the folder structure, but fails on the first file it encounters.
    Update: Exit code of 1.


    I have quickly skimmed the release notes, but I see no mention of a requirement to upgrade the file store for theses particular versions.

    There may be an obvious cause in which case I will post information here.


    Many thanks.
    Last edited by FrostEric; 04-25-2018, 09:20 AM. Reason: v1_10 export

  • #2
    I think that you've got a real bug there. Possibly due to some Windows locking issue. I'm going to guess that some rename() failed - but that should have been reported before the permissions failure.

    But I've got to ask, does the real filename have any WIndows illegal characters in it?

    Comment


    • #3
      Hi. Many thanks.

      Yes, it is suspected to be a Cygwin specific issue:
      [URL]https://www.cygwin.com/ml/cygwin/2018-04/msg00288.html[/URL]
      [URL]https://www.cygwin.com/ml/cygwin/2018-04/msg00289.html[/URL]

      Regards the filename: no, everything in the repositories use Posix naming - there are no Windows related specifics in the code or names.
      Last edited by FrostEric; 04-26-2018, 03:04 PM.

      Comment


      • #4
        Thanks for updating the forum. Please keep us up to date with how this issue is being resolved.

        Also, for the record, what I meant by "Windows illegal characters" would be, for instance, the colon character is something that is not allowed in a file in NTFS (et. al.). Perfectly legal in a linux file system. So if you've got a mixed development environment bad things can happen. This discussion covers some of that space: [url]https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names[/url]

        In any case, appears Cygwin for now. Cheers!

        Comment


        • #5
          Hi,

          Sorry, I can not see my previous update with the links in it.

          In short - it appears to be specific to the Cygwin platform - there is a thread on the subject on the mailing list, with possible resolution sometime after the weekend.

          Understood. No, there is nothing of this sort in the repositories, files, or paths - everything clean in this respect

          Comment


          • #6
            Apologies - I thought I'd approved the post (sometimes posts get kicked over for moderation - not sure what the trigger is): I've just fixed it.

            Comment


            • #7
              This was resolved by a new release of the package for Cygwin on Sat, 2018-04-28.

              Comment


              • #8
                Success! Excellent.

                Comment

                Working...
                X