Burp stops in phase 2 when encountering crazy filename #912
Comments
|
Hello,
Thanks for this.
I am unable to do anything about it for a while, as I am away from
my usual environment. But it does look like what you suggest.
…On Fri, Dec 09, 2022 at 09:55:45AM -0800, Kepi wrote:
Hi,
we encountered problem with backup of one server, which was unclear on client side:
```
2022-12-06 23:00:16 +0100: burp[1584526] Phase 2 begin (send backup data)
fmfm2022-12-06 23:00:28 +0100: burp[1584526] main socket 4: Got network write error
2022-12-06 23:00:28 +0100: burp[1584526] main socket 4: network write problem in asfd_do_write_ssl: 5 - 104=Connection reset by peer
2022-12-06 23:00:28 +0100: burp[1584526] This is probably caused by the peer exiting.
2022-12-06 23:00:28 +0100: burp[1584526] Please check the peer's logs.
```
On server side, problem is immediately clear:
```
2022-12-05 00:45:26 +0100: burp[19233] End phase1 (read previous file system scan)
2022-12-05 00:45:28 +0100: burp[19233] could not mkdir /zhedo/burp/somepath/working/data.tmp/t/somepathonserver/.next/server/pages/employees/123/<p>Jsem kreativní a podporuji kreativitu </<p>Jsem kreativní a podporuji kreativitu </<p>Jsem kreativní a podporuji kreativitu </<p>Jsem kreativní a podporuj
i kreativitu </<p>Jsem kreativní a podporuji kreativitu </<p>Jsem kreativní a podporuji kreativitu </<p>Jsem kreativní a podporuji kreativitu </<p>Jsem kreativní a podporuj2022-12-05 00:45:28 +0100: burp[19233] build path failed2022-12-05 00:45:28 +0100: burp[19233] error in start_to_receive_new_file
2022-12-05 00:45:28 +0100: burp[19233] End phase2 (receive file data)
2022-12-05 00:45:28 +0100: burp[19233] error in backup phase 2
```
The totally crazy name of file on client has been `\<p\>Jsem\ kreativní\ a\ podporuji\ kreativitu \<`.
We fixed this with client on their side, but just wanted to report the problem as, at least from log, it looks like it has some trable with parsing one of characters and created a loop or something?
It would be also great, if in such case backup will continue with skipping problematic file instead of exiting as whole.
Thanks
--
Reply to this email directly or view it on GitHub:
#912
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
|
|
I'm one of these affected by this behavior, it would be great if you changed the app so it would not terminate upon such an error ("crazy filename") and just skipped it (and log what has been skipped) instead. Although the dir name is kind of "crazy", it is still a valid filename (at least on therefore, a backup should not terminate on it, because it effectively makes all the additional backups incomplete :( |
|
I understand.
…On Sun, Dec 11, 2022 at 01:57:54PM -0800, Martin crysman Zahradník wrote:
I'm one of these affected by this behavior, it would be great if you changed the app so it would not terminate upon such an error ("crazy filename") and just skipped it (and log what has been skipped) instead.
Although the dir name is kind of "crazy", it is still a valid filename (at least on `ext4` fs):
therefore, a backup should not terminate on it, because it effectively makes all the additional backups incomplete :(
--
Reply to this email directly or view it on GitHub:
#912 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
|
With the ability to skip backups with long file names, it would probably be more correct to implement (if it possible) some mechanism that would allow burp to backup files with long names. Something like shorten it |
|
Burp already does shorten file names that it thinks are too long. |
|
It's probably something to do with the backslashes getting treated as components in the path and being converted to forward slashes. |
Hi,
we encountered problem with backup of one server, which was unclear on client side:
On server side, problem is immediately clear:
The totally crazy name of file on client has been
\<p\>Jsem\ kreativní\ a\ podporuji\ kreativitu \<.We fixed this with client on their side, but just wanted to report the problem as, at least from log, it looks like it has some trable with parsing one of characters and created a loop or something?
It would be also great, if in such case backup will continue with skipping problematic file instead of exiting as whole.
Thanks
The text was updated successfully, but these errors were encountered: