github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-16 04:42:51 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

dump creates empty zip file #4292

New Issue
Closed
opened 2025-11-02 05:45:02 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-02 05:45:02 -06:00
Owner
Copy Link

Originally created by @muellert on GitHub (Nov 12, 2019).

  • Gitea version (or commit ref): 1.9.5
  • Git version: 2.11
  • Operating system: Debian 9.9 amd64
  • Database (use [x]):
    • [ x] PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • [ x] Not relevant
  • Log gist:

Description

When I try to create a backup, I run 'gitea dump -c /path/to/app.ini -t /var/tmp' because there is not enough space on /tmp.

The result is a directory in /var/tmp. Example (I have repeated this several times):

$ ls -al /var/tmp/gitea-dump-508575557
total 232284
drwx------ 2 _gitea _gitea 4096 Nov 12 23:30 ./
drwxrwxrwt 10 root root 4096 Nov 12 23:29 ../
-rw-r--r-- 1 _gitea _gitea 1362032 Nov 12 23:30 gitea-db.sql
-rw-r--r-- 1 _gitea _gitea 236244910 Nov 12 23:30 gitea-repo.zip
$

The command exits silently with an exit code of 1.

In the directory, from where I started the command, there is an empty zip file, which just has the header:

$ ls -l gitea-dump-1573597794.zip
-rw-r--r-- 1 _gitea _gitea 22 Nov 12 23:29 gitea-dump-1573597794.zip
$

...

Screenshots

Originally created by @muellert on GitHub (Nov 12, 2019). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): 1.9.5 - Git version: 2.11 - Operating system: Debian 9.9 amd64 - Database (use `[x]`): - [ x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ x] Not relevant - Log gist: ## Description When I try to create a backup, I run 'gitea dump -c /path/to/app.ini -t /var/tmp' because there is not enough space on /tmp. The result is a directory in /var/tmp. Example (I have repeated this several times): $ ls -al /var/tmp/gitea-dump-508575557 total 232284 drwx------ 2 _gitea _gitea 4096 Nov 12 23:30 ./ drwxrwxrwt 10 root root 4096 Nov 12 23:29 ../ -rw-r--r-- 1 _gitea _gitea 1362032 Nov 12 23:30 gitea-db.sql -rw-r--r-- 1 _gitea _gitea 236244910 Nov 12 23:30 gitea-repo.zip $ The command exits silently with an exit code of 1. In the directory, from where I started the command, there is an empty zip file, which just has the header: $ ls -l gitea-dump-1573597794.zip -rw-r--r-- 1 _gitea _gitea 22 Nov 12 23:29 gitea-dump-1573597794.zip $ ... ## Screenshots <!-- **If this issue involves the Web Interface, please include a screenshot** -->
GiteaMirror added the issue/staletype/bug labels 2025-11-02 05:45:02 -06:00
GiteaMirror commented 2025-11-02 05:45:03 -06:00
Author
Owner
Copy Link

@JacquesOfAllTrades commented on GitHub (Nov 26, 2019):

Gitea: 1.9.5
Git: 2.17.1
OS: Ubuntu Server 18.04.3 LTS
Database: PosgreSQL

Same problem here, with or without the --tempdir option.

The command I'm running, with relevant output (paths changed for privacy):

$ gitea dump -c /jacques/git/home/custom/conf/app.ini -f "gitea-20191126.zip" -V
2019/11/26 17:15:47 ...dules/setting/git.go:83:newGit() [I] Git Version: 2.17.1
Adding dir.../jacques/git/repositories/jacques
Adding dir.../jacques/git/repositories/jacques/jacques-website.git
Adding file.../jacques/git/repositories/jacques/jacques-website.git/config
[...lines cut for brevity...]
Adding dir.../jacques/git/repositories/user1
Adding dir.../jacques/git/repositories/user2
$

There's no error logged, but the result is an empty .zip file:

$ ls -l
-rw-rw-r-- 1 git git        22 Nov 26 17:15 gitea-20191126.zip

Meanwhile, the contents of the dump are left in the temp directory:

$ ls -l /tmp
drwx------ 2 git  git  4096 Nov 26 17:16 gitea-dump-745428022
$ ls -l /tmp/gitea-dump-745428022/
-rw-rw-r-- 1 git git   1163586 Nov 26 17:16 gitea-db.sql
-rw-rw-r-- 1 git git 859719475 Nov 26 17:16 gitea-repo.zip

The same dump command worked fine with Gitea 1.9.1.

Thanks for all your work, devs! I've been using Gitea since about 1.5 and am very happy overall.

@JacquesOfAllTrades commented on GitHub (Nov 26, 2019): Gitea: 1.9.5 Git: 2.17.1 OS: Ubuntu Server 18.04.3 LTS Database: PosgreSQL Same problem here, with or without the `--tempdir` option. The command I'm running, with relevant output (paths changed for privacy): ``` $ gitea dump -c /jacques/git/home/custom/conf/app.ini -f "gitea-20191126.zip" -V 2019/11/26 17:15:47 ...dules/setting/git.go:83:newGit() [I] Git Version: 2.17.1 Adding dir.../jacques/git/repositories/jacques Adding dir.../jacques/git/repositories/jacques/jacques-website.git Adding file.../jacques/git/repositories/jacques/jacques-website.git/config [...lines cut for brevity...] Adding dir.../jacques/git/repositories/user1 Adding dir.../jacques/git/repositories/user2 $ ``` There's no error logged, but the result is an empty .zip file: ``` $ ls -l -rw-rw-r-- 1 git git 22 Nov 26 17:15 gitea-20191126.zip ``` Meanwhile, the contents of the dump are left in the temp directory: ``` $ ls -l /tmp drwx------ 2 git git 4096 Nov 26 17:16 gitea-dump-745428022 $ ls -l /tmp/gitea-dump-745428022/ -rw-rw-r-- 1 git git 1163586 Nov 26 17:16 gitea-db.sql -rw-rw-r-- 1 git git 859719475 Nov 26 17:16 gitea-repo.zip ``` The same dump command worked fine with Gitea 1.9.1. Thanks for all your work, devs! I've been using Gitea since about 1.5 and am very happy overall.
GiteaMirror commented 2025-11-02 05:45:04 -06:00
Author
Owner
Copy Link

@JacquesOfAllTrades commented on GitHub (Nov 26, 2019):

Additional info: The problem occurs with or without the -f/--file option. Without -f, I just end up with an empty ZIP file with the default name. :)

@JacquesOfAllTrades commented on GitHub (Nov 26, 2019): Additional info: The problem occurs with or without the `-f`/`--file` option. Without `-f`, I just end up with an empty ZIP file with the default name. :)
GiteaMirror commented 2025-11-02 05:45:04 -06:00
Author
Owner
Copy Link

@JacquesOfAllTrades commented on GitHub (Nov 26, 2019):

Aaaand the relevant snippet from /var/log/gitea/gitea.log:

2019/11/26 17:15:47 ...dules/setting/log.go:269:newLogService() [I] Gitea Log Mode: File(File:info)
2019/11/26 17:15:47 ...les/setting/cache.go:42:newCacheService() [I] Cache Service Enabled
2019/11/26 17:15:47 ...s/setting/session.go:45:newSessionService() [I] Session Service Enabled
2019/11/26 17:15:47 ...es/setting/mailer.go:105:newMailService() [I] Mail Service Enabled
2019/11/26 17:15:47 ...es/setting/mailer.go:116:newRegisterMailService() [I] Register Mail Service Enabled
2019/11/26 17:15:47 ...es/setting/mailer.go:127:newNotifyMailService() [I] Notify Mail Service Enabled
2019/11/26 17:15:47 cmd/dump.go:76:runDump() [I] Creating tmp work dir: /tmp/gitea-dump-745428022
2019/11/26 17:15:47 cmd/dump.go:86:runDump() [I] Packing dump files...
2019/11/26 17:15:47 cmd/dump.go:96:runDump() [I] Dumping local repositories.../jacques/git/repositories
2019/11/26 17:16:40 cmd/dump.go:110:runDump() [I] Dumping database...
2019/11/26 17:16:41 cmd/dump.go:122:runDump() [I] Adding custom configuration file from /jacques/git/home/custom/conf/app.ini
2019/11/26 17:22:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT "id", "lower_name", "name", "full_name", "email", [...]

The last relevant line is "Adding ... app.ini". Interestingly, after the dump command exits, the temp directory contains the repository and database dumps, but it doesn't contain app.ini. So it seems that step must have caused the dump to abort, but without any error being logged.

@JacquesOfAllTrades commented on GitHub (Nov 26, 2019): Aaaand the relevant snippet from /var/log/gitea/gitea.log: ``` 2019/11/26 17:15:47 ...dules/setting/log.go:269:newLogService() [I] Gitea Log Mode: File(File:info) 2019/11/26 17:15:47 ...les/setting/cache.go:42:newCacheService() [I] Cache Service Enabled 2019/11/26 17:15:47 ...s/setting/session.go:45:newSessionService() [I] Session Service Enabled 2019/11/26 17:15:47 ...es/setting/mailer.go:105:newMailService() [I] Mail Service Enabled 2019/11/26 17:15:47 ...es/setting/mailer.go:116:newRegisterMailService() [I] Register Mail Service Enabled 2019/11/26 17:15:47 ...es/setting/mailer.go:127:newNotifyMailService() [I] Notify Mail Service Enabled 2019/11/26 17:15:47 cmd/dump.go:76:runDump() [I] Creating tmp work dir: /tmp/gitea-dump-745428022 2019/11/26 17:15:47 cmd/dump.go:86:runDump() [I] Packing dump files... 2019/11/26 17:15:47 cmd/dump.go:96:runDump() [I] Dumping local repositories.../jacques/git/repositories 2019/11/26 17:16:40 cmd/dump.go:110:runDump() [I] Dumping database... 2019/11/26 17:16:41 cmd/dump.go:122:runDump() [I] Adding custom configuration file from /jacques/git/home/custom/conf/app.ini 2019/11/26 17:22:55 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT "id", "lower_name", "name", "full_name", "email", [...] ``` The last relevant line is "Adding ... app.ini". Interestingly, after the dump command exits, the temp directory contains the repository and database dumps, but it doesn't contain app.ini. So it seems that step must have caused the dump to abort, but without any error being logged.
GiteaMirror commented 2025-11-02 05:45:04 -06:00
Author
Owner
Copy Link

@JacquesOfAllTrades commented on GitHub (Nov 27, 2019):

Well, I'm at a loss. It's working now, and damned if I know what I did to fix it.

The only persistent changes that I made relate to the host system and really don't explain how the issue might've been fixed:

  • Ran some system updates (about 20 packages updated) and rebooted, but the dump did not work after that.
  • Freed up some space on the root partition, dumps were still failing afterwards. (The Gitea installation, DB, repos, and backup destination are all on a /jacques partition with tons of space, and I was using -t to put the temp files on that partition as well).
  • Disabled the swapfile and gave the system a couple more GB of RAM (it's a virtual machine). Dumps began working around the time I changed the swap settings, but it makes no sense that that would be related unless dump has some crazy sensitivity to timing.

I didn't change app.ini (or any other config files aside from a couple related to swapfile settings), I'm using the same Gitea executable as before, and I'm running dump with the same parameters as before.

The whole thing is completely baffling. I can only guess that there could've been multiple issues compounding to cause the failure, but at this point I'm just happy that it's working again. I'll have to wait and see if the dump succeeds when run by the weekly cron job later in the week.

@JacquesOfAllTrades commented on GitHub (Nov 27, 2019): Well, I'm at a loss. It's working now, and damned if I know what I did to fix it. The only persistent changes that I made relate to the host system and really don't explain how the issue might've been fixed: - Ran some system updates (about 20 packages updated) and rebooted, but the dump *did not* work after that. - Freed up some space on the root partition, dumps were still failing afterwards. (The Gitea installation, DB, repos, and backup destination are all on a `/jacques` partition with tons of space, and I was using `-t` to put the temp files on that partition as well). - Disabled the swapfile and gave the system a couple more GB of RAM (it's a virtual machine). Dumps began working *around* the time I changed the swap settings, but it makes no sense that that would be related unless dump has some crazy sensitivity to timing. I **didn't** change app.ini (or any other config files aside from a couple related to swapfile settings), I'm using the same Gitea executable as before, and I'm running `dump` with the same parameters as before. The whole thing is completely baffling. I can only guess that there could've been multiple issues compounding to cause the failure, but at this point I'm just happy that it's working again. I'll have to wait and see if the dump succeeds when run by the weekly cron job later in the week.
GiteaMirror commented 2025-11-02 05:45:04 -06:00
Author
Owner
Copy Link

@JacquesOfAllTrades commented on GitHub (Dec 4, 2019):

I've got a new theory on the cause of my problem: At the time when the dump was failing for me, I had a copy of app.ini (named something like app-20191123.bak) in the .../git/home/custom/conf directory, but it was owned by root:root instead of git:git. Thus, when gitea dump tried to back up the conf directory, it didn't have permission to copy that file, and so the dump failed. (I haven't tried to recreate the problem, but I'm happy with this explanation.)

Due to issue #9218, Gitea didn't output any error message to indicate why it aborted the operation, so I was unable to identify my own mistake. Maybe the OP could be in a similar situation that can be resolved once the logging fix is deployed.

@JacquesOfAllTrades commented on GitHub (Dec 4, 2019): I've got a new theory on the cause of my problem: At the time when the dump was failing for me, I had a copy of `app.ini` (named something like `app-20191123.bak`) in the `.../git/home/custom/conf` directory, but it was owned by `root:root` instead of `git:git`. Thus, when `gitea dump` tried to back up the `conf` directory, it didn't have permission to copy that file, and so the dump failed. (I haven't tried to recreate the problem, but I'm happy with this explanation.) Due to issue #9218, Gitea didn't output any error message to indicate why it aborted the operation, so I was unable to identify my own mistake. Maybe the OP could be in a similar situation that can be resolved once the logging fix is deployed.
GiteaMirror commented 2025-11-02 05:45:05 -06:00
Author
Owner
Copy Link

@muellert commented on GitHub (Dec 4, 2019):

This is an interesting theory, and yes, I have lot of files like that as well, since I install and upgrade gitea via Ansible, and, for safety reasons, have Ansible keep backup files of the configurations. These end up being owned by root:root and named eg. "app.ini.22648.2019-08-03@13:18:47~". I don't think the presence of such files should break the backup. Maybe the backup should be restricted to files which are actually required for restoring a running gitea - ie, ignore those backup files? I am not sure.

@muellert commented on GitHub (Dec 4, 2019): This is an interesting theory, and yes, I have lot of files like that as well, since I install and upgrade gitea via Ansible, and, for safety reasons, have Ansible keep backup files of the configurations. These end up being owned by root:root and named eg. "app.ini.22648.2019-08-03@13:18:47~". I don't think the presence of such files should break the backup. Maybe the backup should be restricted to files which are actually required for restoring a running gitea - ie, ignore those backup files? I am not sure.
GiteaMirror commented 2025-11-02 05:45:05 -06:00
Author
Owner
Copy Link

@AndreasSummer commented on GitHub (Dec 19, 2019):

Have the same issue with windows and administrator rights. Got an temp folder with an sql an a zip file with all the repository in it.

C:\gitea\gitea.exe dump -c C:\Gitea\custom\conf\app.ini -tempdir D:\backup\gitea -f D:\backup\gitea\backup.zip

@AndreasSummer commented on GitHub (Dec 19, 2019): Have the same issue with windows and administrator rights. Got an temp folder with an sql an a zip file with all the repository in it. C:\gitea\gitea.exe dump -c C:\Gitea\custom\conf\app.ini -tempdir D:\backup\gitea -f D:\backup\gitea\backup.zip
GiteaMirror commented 2025-11-02 05:45:05 -06:00
Author
Owner
Copy Link

@GAS85 commented on GitHub (Feb 7, 2020):

Try this theory and seems it does not work for me, I also have had backup file of app.ini owned by root, changing ownership to git does not help me at all. Even I move out backup file form the config directory, but it does not help too.

@GAS85 commented on GitHub (Feb 7, 2020): Try this theory and seems it does not work for me, I also have had backup file of app.ini owned by root, changing ownership to git does not help me at all. Even I move out backup file form the config directory, but it does not help too.
GiteaMirror commented 2025-11-02 05:45:05 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Apr 7, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Apr 7, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.
GiteaMirror commented 2025-11-02 05:45:06 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Apr 25, 2020):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Apr 25, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/stale type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4292
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?