Bug 3591 - (int-87424) backup will loop nearly infinitely for directories named #foo because backup isn't properly url escaping directory names
(int-87424)
: backup will loop nearly infinitely for directories named #foo because backup ...
Status: CLOSED FIXED
Product: Settings and Maintenance
Backup/Restore
: 4.1.1 (4.2008.30-2)
: N810 Maemo
: Medium major with 3 votes (vote)
: 4.1.2
Assigned To: unassigned
: backup-restore-bugs
:
:
:
: 3588
  Show dependency tree
 
Reported: 2008-08-15 20:34 UTC by timeless
Modified: 2008-10-09 16:21 UTC (History)
5 users (show)

See Also:


Attachments
testcase (1.10 KB, application/x-deb)
2008-08-18 16:22 UTC, timeless
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description timeless (reporter) 2008-08-15 20:34:18 UTC
preconditions:
1. install claws
this will install: /etc/osso-backup/applications/claws-mail.conf

which contains:
  <location type="dir"
category="settings">/home/user/.claws-mail/tagsdb</location>

2. configure it so that it has a #imap directory.
  This may happen automatically or you may need to configure imap, I dunno. if
it doesn't, you could create it.

3. install strace and run strace -f -p `pidof maemo-launcher`

4. run backup and ask it to backup settings

the log will show:
[pid  1863] open("/home/user/.claws-mail/tagsdb",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10
[pid  1863] fstat64(10, {st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid  1863] fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
[pid  1863] getdents64(10, /* 3 entries */, 4096) = 80
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/.", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/..", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/#imap",
{st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid  1863] stat64("/home/user/.claws-mail/tagsdb/", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] open("/home/user/.claws-mail/tagsdb/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11
[pid  1863] fstat64(11, {st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid  1863] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid  1863] getdents64(11, /* 3 entries */, 4096) = 80
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/.", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/..", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/#imap",
{st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid  1863] stat64("/home/user/.claws-mail/tagsdb/", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] open("/home/user/.claws-mail/tagsdb/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 12
[pid  1863] fstat64(12, {st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid  1863] fcntl64(12, F_SETFD, FD_CLOEXEC) = 0
[pid  1863] getdents64(12, /* 3 entries */, 4096) = 80
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/.", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/..", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] lstat64("/home/user/.claws-mail/tagsdb/#imap",
{st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid  1863] stat64("/home/user/.claws-mail/tagsdb/", {st_mode=S_IFDIR|0700,
st_size=0, ...}) = 0
[pid  1863] open("/home/user/.claws-mail/tagsdb/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
[pid  1863] fstat64(13, {st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid  1863] fcntl64(13, F_SETFD, FD_CLOEXEC) = 0
[pid  1863] getdents64(13, /* 3 entries */, 4096) = 80

the problem is that '#' is the url fragment indicator, so when backup asks
gnomevfs to open the what it thought was a subdirectory, gnomevfs instead opens
the tagsdb directory.

the code of course is recursive, so it will keep doing this until it hits the
max file limit (going nowhere recursively)
Comment 1 timeless (reporter) 2008-08-15 20:35:21 UTC
oh right, kaie has claws-mail version 3.5.0 installed fwiw. but it doesn't
matter, the bug is in the backup application (there are other bugs to be filed
for claws itself, its conf file is buggy)
Comment 2 timeless (reporter) 2008-08-16 22:23:10 UTC
*** Bug 3425 has been marked as a duplicate of this bug. ***
Comment 3 timeless (reporter) 2008-08-17 17:22:15 UTC
oh, fwiw, this is also the reason that purple gets stuck.

because channels are typically named #foo.

I'm not sure what a purple is, but...

[pid 1863]
lstat64("/home/user/.purple/logs/irc/user@irc.mozilla.org/#something.chat",
{st_mode=S_IFDIR|0700, st_size=0, ...}) = 0

note that S_IFDIR bit, i'm fairly certain that
/home/user/.purple/logs/irc/user@irc.mozilla.org/#something.chat is a directory

[pid  1863] stat64("/home/user/.purple/logs/irc/user@irc.mozilla.org/",
{st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid  1863] open("/home/user/.purple/logs/irc/user@irc.mozilla.org/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 EMFILE (Too many open files)
Comment 4 timeless (reporter) 2008-08-18 16:22:33 UTC
Created an attachment (id=877) [details]
testcase

i made this testcase and lbt tested it (thanks). i'm attaching it for
posterity. it's also attached to the internal bugzilla (i've had a bad weekend,
otherwise i'd have attached it here yesterday).
Comment 5 Eero Tamminen nokia 2008-08-25 11:44:13 UTC
Fixed in next release.
Comment 6 Andre Klapper maemo.org 2008-09-03 22:08:13 UTC
Fixed in package
osso-backup 1.6.9-3
which is part of the internal build version
diablo build 4.2008.34

Any public update released with or after this build version will include the
fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


(Using this template for fixed bugs to reset Target Milestones correctly later
on and make it easier to create ChangeLogs. Sorry for the email noise.)
Comment 7 Andre Klapper maemo.org 2008-09-29 15:38:40 UTC
Fix included in today's 4.2008.36-5 update.
Comment 8 Lucas Maneos 2008-09-29 16:55:42 UTC
Confirmed, a full (including settings/email) backup deadlocked before the
update but works fine now.
Comment 9 Andre Klapper maemo.org 2008-09-29 17:02:45 UTC
Thanks!
Comment 10 David Mery 2008-10-06 19:53:49 UTC
Fix verified as well.