Invalidated shares handling

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install Mollify 2.1 alongside an existing 1.8.9.3 install (I can't do a 
straight upgrade until I've got the kinks worked out...)
2. Configure Shares plugin to be on.
3. Click on Configuration link in header, Click on "Shares" link in sidebar.

What is the expected output? What do you see instead?
Expected output is a list of shares. Instead, I am presented with a login 
screen.

What version of the product are you using? On what operating system?
2.1, Mountain Lion Server

Please provide any additional information below.
Non-debug Apache error log shows:

[Wed Sep 11 14:22:38 2013] [error] [client 192.168.10.100] MOLLIFY ERROR: 
ServiceException: UNAUTHORIZED=, referer: https://my.server.name/mollify.new/
[Wed Sep 11 14:22:38 2013] [error] [client 192.168.10.100] MOLLIFY ERROR: 
{0:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/services/ServicesBase.class.php, line:80, 
function:item, class:FilesystemController, type:->, args:{0:4f12724fa2948}}, 
1:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/plugin/Share/ShareServices.class.php, line:30, 
function:item, class:ServicesBase, type:->, args:{0:4f12724fa2948}}, 
2:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/services/ServicesBase.class.php, line:53, 
function:processGet, class:ShareServices, type:->, args:{}}, 
3:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/MollifyBackend.class.php, line:82, 
function:processRequest, class:ServicesBase, type:->, args:{}}, 
4:{file:/Volumes/Storage/File Transfer Folder/mollify.new/backend/r.php, 
line:53, function:processRequest, class:MollifyBackend, type:->, 
args:{0:Request}}}, referer: https://my.server.name/mollify.new/

Original issue reported on code.google.com by tom.ie...@gmail.com on 11 Sep 2013 at 6:25

[GoogleCodeExporter]

Could not reproduce this out of the box on my test env.

From the debug log, the only logical reason for the UNAUTHORIZED error is that 
the user does not have permissions for the root folder where the shared item 
exists. In fact, I could make this happen by deliberately changing the user 
default permission to none, after the share was done. Could your case be 
something similar?

Original comment by samuli.j...@gmail.com on 11 Sep 2013 at 7:07

[GoogleCodeExporter]

Are you talking about the user from Mollify's perspective, or the web server 
user?

The user I'm logging into Mollify as has Administrative privileges within 
Mollify.

Could it be a folder or file which doesn't exist anymore?

Original comment by tom.ie...@gmail.com on 11 Sep 2013 at 7:27

[GoogleCodeExporter]

Yes, from Mollify perspective. But if it's admin, then I suppose non-existing 
folder is more likely explanation.

I'm changing the behaviour so that share listing won't throw the error in this 
case, instead it ignores the invalid share and will add error log entry. Not 
sure if it's good enough, but at least better.

Just uploaded 2.0.2, you could try with that. Once you click the share list 
view open, wIth debug log it will give some more info on what's wrong (in the 
log file).

Original comment by samuli.j...@gmail.com on 12 Sep 2013 at 5:46

[GoogleCodeExporter]

I've updated to 2.0.3, and while it's better, it's still failing on 
non-existent files.

I saw log entries where the share was invalid, but which didn't cause an 
execution-halting error. Those looked like this:

[Thu Sep 12 16:41:33 2013] [error] [client 192.168.10.100] MOLLIFY ERROR: 
Invalid share item: 4f12724fa2948, referer: https://my.server.name/mollify.new/

The bad shares which still cause execution halting generate errors which look 
like this:

[Thu Sep 12 16:45:00 2013] [error] [client 192.168.10.100] MOLLIFY ERROR: PHP 
error #2, filesize() [<a href='function.filesize'>function.filesize</a>]: stat 
failed for /Volumes/Storage/Software/filename.dmg (/Volumes/Storage/File 
Transfer 
Folder/mollify.new/backend/include/filesystem/LocalFilesystem.class.php:317)\n{0
:{function:globalErrorHandler, args:{0:2, 1:filesize() [<a 
href='function.filesize'>function.filesize</a>]: stat failed for 
/Volumes/Storage/Software/filename.dmg, 2:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/filesystem/LocalFilesystem.class.php, 3:317, 
4:{file:FILESYSTEMITEM File (LocalFilesystem): [51f6f7d73fecf] = 'filename.dmg' 
(filename.dmg)}}}, 1:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/filesystem/LocalFilesystem.class.php, 
line:317, function:filesize, args:{0:/Volumes/Storage/Software/filename.dmg}}, 
2:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/filesystem/FilesystemItem.class.php, 
line:128, function:size, class:LocalFilesystem, object:LOCAL (3) 
Software(/Volumes/Storage/Software/), type:->, args:{0:FILESYSTEMITEM File 
(LocalFilesystem): [51f6f7d73fecf] = 'filename.dmg' (filename.dmg)}}, 
3:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/filesystem/FilesystemItem.class.php, 
line:149, function:size, class:File, object:FILESYSTEMITEM File 
(LocalFilesystem): [51f6f7d73fecf] = 'filename.dmg' (filename.dmg), type:->, 
args:{}}, 4:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/plugin/Share/ShareServices.class.php, line:37, 
function:data, class:File, object:FILESYSTEMITEM File (LocalFilesystem): 
[51f6f7d73fecf] = 'filename.dmg' (filename.dmg), type:->, args:{}}, 
5:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/services/ServicesBase.class.php, line:53, 
function:processGet, class:ShareServices, object:ShareServices, type:->, 
args:{}}, 6:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/include/MollifyBackend.class.php, line:82, 
function:processRequest, class:ServicesBase, object:ShareServices, type:->, 
args:{}}, 7:{file:/Volumes/Storage/File Transfer 
Folder/mollify.new/backend/r.php, line:53, function:processRequest, 
class:MollifyBackend, object:MollifyBackend, type:->, args:{0:Request}}}, 
referer: https://my.server.name/mollify.new/

I've deleted (from mollify_share in mysql) all shares from my user which were 
invalid.

I looked into one which was giving the above error and the file wasn't there 
anymore.

In my use-case, more manipulation of the underlying filesystem happens than 
through Mollify, so the likelihood of a share's underlying item being moved, 
renamed or deleted is quite likely.

Original comment by tom.ie...@gmail.com on 12 Sep 2013 at 8:55

[GoogleCodeExporter]

I've added more checks at the share listing, which should prevent this error as 
well. Coming in next release.

But overall this is a problematic issue. If you are modifying the filesystem 
"behind" mollify, there is absolutely no way for mollify to know what has 
happened. For example if you rename or move the file somewhere else, for 
mollify it is same as if the file is deleted (it does not exist there anymore, 
and we cannot know if it went somewhere else), and the only logical way to act 
is to accept that shares are invalid.

The question here is, what to do about the invalid shares? Should the user be 
notified about them (would that make any difference, because is there anything 
to do)? Or just silently delete them?

Original comment by samuli.j...@gmail.com on 13 Sep 2013 at 11:25

[GoogleCodeExporter]

I agree that this is a problematic issue.

I don't feel that it's Mollify's job to try to find shared files which have 
moved.

I'd say marking shares as invalid in the UI would be enough for most. For my 
use, deleting the shares when found invalid wouldn't be a bad choice.

When I wrote a file manager (before I found Mollify) I strove for consistency 
with the filesystem using localized updates when viewing a directory, and a 
nightly cron which recursed the filesystem updating for changes. Of course, I 
also used disk UUID and inode numbers as foreign keys in the database, so it 
was easy to keep track of in-directory renames.

I imagine you have code to sync the mollify_item_id table with the filesystem. 
What do you do when there are deletions or renames in the filesystem that put 
the db out of consistency? Could these routines have additional consistency 
checking of the shares table?

Original comment by tom.ie...@gmail.com on 13 Sep 2013 at 2:16

[GoogleCodeExporter]

Yes, I suppose showing invalid shares in UI would be logical. I'll add it to my 
list.

In mollify item_id table holds unique and permanent ids for files and folders. 
They are created lazily whenever a item path is not found, and if the item is 
renamed/moved in mollify, then the mapping is updated. This way any other table 
referring to the file or folder does not need updating.

At the moment there is no cleaning/sync task (has been on my list), so 
inconsistencies remain in the table. But you are right, the same 
cleaning/checking task could do other tasks as well, like share validation.

Original comment by samuli.j...@gmail.com on 13 Sep 2013 at 4:16

[GoogleCodeExporter]

Original comment by samuli.j...@gmail.com on 13 Sep 2013 at 4:17

• Changed title: Invalidated shares handling
• Changed state: Accepted

[GoogleCodeExporter]

Invalid shares hilighted in version 2.0.4

Original comment by samuli.j...@gmail.com on 15 Sep 2013 at 7:18

[GoogleCodeExporter]

Thanks for the fix in 2.0.4. Implementation works great!

Original comment by tom.ie...@gmail.com on 18 Sep 2013 at 12:49

[GoogleCodeExporter]

Currently no plans to implement further functionality for invalid share handling

Original comment by samuli.j...@gmail.com on 20 Jan 2015 at 12:07

• Changed state: Fixed