[Owncloud] Fwd: Re: Files_Sharing Update

[Michael Gapczynski]

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 <blizzz at owncloud.com>
> To: Michael Gapczynski <mtgap at owncloud.com>
> 
> 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