On Tuesday, September 25, 2012 05:51:06 PM Arthur Schiwon wrote: > and to the list > > ---------- Forwarded Message ---------- > > Subject: Re: [Owncloud] Files_Sharing Update > Date: Tuesday, September 25, 2012, 05:49:20 PM > From: Arthur Schiwon <[email protected]> > To: Michael Gapczynski <[email protected]> > > On Tuesday, September 25, 2012 11:17:29 AM you wrote: > > Thanks for working on this Arthur. I'm not quite sure what's going on with > > the user backends not setup because I haven't run into any of those issues > > myself. It seemed that the database user backend was always running when I > > did an upgrade. This should probably be documented somewhere or the user > > backends loaded before triggering an upgrade. > > I agree I was puzzled bout it. I believe it is because it's an major upgrade > which is done in init() before the user backends are created and which also > takes the apps into account. > > > What do you mean that there will be collisions with the old table still > > existing? Nothing should be using the oc_sharing table. > > I was a bit unprecise. When the update is not successful, it will be tried > all over again on the next page request. The already transfered shares will > flood then the screen with error messages like "already exists" and fail > again.
Well that doesn't sound like a good way to do app upgrades. I say bump the version up no matter what for any app upgrade. If an upgrade scripts fails the first time, there's a good chance it will fail again. About the exceptions, I think Bart wrapped the app upgrade in a try catch so there shouldn't be any errors shown to the user. No need for logging stuff in the actual upgrade because the Share API does that. > > I didn't want to > > delete it this release in case there were upgrade issues, which there are > > ;) If we do a 4.5.1 and no issues are reported we can delete it then. No > > harm in having it sit around. > > > > Can you give more details about the rows being added for links? > > In the old table i have had > +-----------+-----------------+--------------------------------------------- > ------------------+------------------------------------------+-------------+ > | uid_owner | uid_shared_with | source > | target | permissions | > > +-----------+-----------------+--------------------------------------------- > ------------------+------------------------------------------+-------------+ > | nata | public | /path/to/shared/folder | > > 4d24e8c45f5f198f628a34547b1176e4f223497a | 0 | > > | arthur | public | /path/to/shared/folder | > > 4d24e8c45f5f198f628a34547b1176e4f223497a | 0 | > > | arthur | public | /path/to/shared/folder | > > 4d24e8c45f5f198f628a34547b1176e4f223497a | 0 | > +-----------+-----------------+--------------------------------------------- > ------------------+------------------------------------------+-------------+ > (here one row is already doubled, because in 4.0.7 the link was not shown > in the GUI for me – so i clicked it again) > > In the new share table however i do not see any shares of the item type > "link" or similar. How are they stored? > > However, the new link looks like > https://owncloud.server/public.php?service=files&file=/path/to/shared/folder > > the old link was: > https://owncloud.server/public.php?service=files&token=20288a20dd02750f81d23 > 07e32bd367dcda331b6&file=/path/to/shared/folder Now I think I understand, you can't use the old link because we aren't using tokens anymore. The share_type for links is 3 in the database. > > Does it help you? > > Cheers > Arthur _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
