Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
Original comment by samuli.j...@gmail.com
on 13 Sep 2013 at 4:17
Invalid shares hilighted in version 2.0.4
Original comment by samuli.j...@gmail.com
on 15 Sep 2013 at 7:18
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
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
Original issue reported on code.google.com by
tom.ie...@gmail.com
on 11 Sep 2013 at 6:25