On Tue, Dec 30, 2014 at 5:03 PM, Greg Earle <[email protected]> wrote:

> On Dec 30, 2014, at 4:37 PM, Ryan Ollos wrote:
>
> > The upgrade step moves the attachment files to
> /var/trac/projects_backups/test_project/files
> >
> > You could avoid the error by removing the files that can't be moved
> because they aren't linked to any resource.  It shouldn't be a problem to
> leave them though.  I suspect that the upgrade step completed normally and
> you are just looking in the wrong place for your attachments.
>
> Thanks Ryan.  Here are the two trees, for comparison:
>
> [root@newtracserver test_project]# ls -RF attachments
> attachments:
> wiki/
>
> attachments/wiki:
> PeerReviews/  TemplateHelp/
>
> attachments/wiki/PeerReviews:
> PeerReviewsHelp/  RFAForm.doc
>
> attachments/wiki/PeerReviews/PeerReviewsHelp:
> RFA_doc.png  RFA_ticket.png
>
> attachments/wiki/TemplateHelp:
> trac_layout.png
>
> [root@newtracserver test_project]# ls -RF files/attachments
> files/attachments:
> wiki/
>
> files/attachments/wiki:
> 59b/  f09/
>
> files/attachments/wiki/59b:
> 59b035367211a9382930b2a4c13637dbc33c4f32/
>
> files/attachments/wiki/59b/59b035367211a9382930b2a4c13637dbc33c4f32:
> 05743b143f4c78aa749c2d470277f348d794ec10.xlsx
>  a015d37c8276982d00418efbca68e1fce6d7de1a.xls
> 5a1c1d74842bfa9f49ed47d53855d738e9a85ad3.graffle
> f14c977b31670d231960c854894868ddf0ac55ff.graffle
>
> files/attachments/wiki/f09:
> f0955265d583361233790e2a4da795373c345a9f/
>
> files/attachments/wiki/f09/f0955265d583361233790e2a4da795373c345a9f:
> f0290dad815e9d1aa5a9a19714a904d72373c953.png
>
> The 4 "59b" attachments were from the old "Design" wiki attachment
> directory;
> the "f09" PNG file is from the "WikiStart" wiki attachment directory.  (The
> ones that no longer exist in the 'new' Project after "trac-admin upgrade"
> was run.)
>

The only reason it should skip those files is if they aren't referenced in
the attachments table. Could you print out the contents of the table? If
using SQLite and you have the sqlite3 command line tool installed, it's
simply:

$ sqlite3 tracdev/db/trac.db
sqlite> SELECT type,id,filename FROM attachment;

Also useful would be:
sqlite> SELECT value FROM system WHERE name='database_version'

> If you don't find the attachments in the "files" directory, then we might
> have another case of this issue:
> >
> > http://trac.edgewall.org/ticket/11370
>
> Seems like a distinct possibility.  I note again that, given the above,
> some of the attachments were migrated to "files" just fine, but once it
> hit that one sub-subdirectory with the 2 PNG files, it stopped dead in
> its tracks - none of the rest of them got migrated (i.e., in addition
> to the 2 PNG files, it also did not go on and migrate "RFAForm.doc" either.
>
> Given the mention of an "early return" in 11370, perhaps this is what is
> happening here?
>

It seems possible, but I've never been able to see a mechanism that could
force an early return without also resulting in an Exception and traceback
(not the "can't remove directories" one that you see).


> So ... do I swap out "db28.py" for the trac-hacks' #11151 "run-db28.py"
> to try and debug it?
>

Some users have reported success in using the "run-db28.py" script to move
attachments after the upgrade was completed.


> Or just remove the new project, copy it in again from the backup, and
> run "trac-admin upgrade" under "strace -f" and pick through the rubble?
>
> Thanks,
>
>         - Greg
>

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to