[Building Sakai] Proposed Kernel Mod: disallow empty attachments from being added

[Matthew Jones]

I can't think of a good reason at the moment, but that also doesn't mean it
couldn't exist. Creating an empty 0KB resource is the purpose of the "touch"
command in unix and I use that pretty often. There might be some tool out
there that creates a file and based on the presence or absence something
happens.

So if you did it in the kernel, it seems like it would need to be a new API
just so that old functionality could be retained "just in case" which is
usually a good thing, since there's so many contrib tools out there and
special uses that we don't know about. You'd do this in the addResource.
This already catches for quota exceptions, and a minimum quota would be
similar to a maximum.

// Something like adding an additional parameter either for minimum size or
a boolean to allow 0KB or not.
        public ContentResource addResource(String id, String type,
InputStream content, ResourceProperties properties, Collection groups, int
priority, long minSizeAllowed)

. . . I think changing the default behavior globally (even if a property was
involved) would require more +1's.

This would for sure be easier than adding it, then checking the size later
and removing it if your tool doesn't want to allow 0 byte resources?

-Matthew

On Fri, Mar 18, 2011 at 3:02 PM, Sam Ottenhoff <ottenhoff at longsight.com>wrote:

>  I can't think of any good reason for a 0kb resource.  A kernel mod seems
> like the correct route.
>
> The only place I know of where 0kb resources are uploaded (and ignored) is
> the Assignments tool -> Upload All (empty comments files).
>
> --Sam
>
>
> On 3/18/2011 2:56 PM, York, Adam wrote:
>
>  While investigating the JIRA SAK-7335 (
> https://jira.sakaiproject.org/browse/SAK-7334 )  I came across an issue
> which spanned 'Assignments' and 'File Picker Helper Tool'.  The problem
> appears to be best solved with a modification of the kernel.
>
>  The issue encountered is that the user is allowed to attach 0kb files.
>  This is problematic when submitting assignments, and in general is not
> something the user should be allowed to do for various reasons.  Perhaps the
> best case is when a user submits a 0kb file and isn't aware of it or does it
> for malicious reasons (unofficial extension).  I discussed it with fellow
> team members Zhen Qian and Dave Haines.  The general consensus was that the
> problem was best corrected at the kernel level when adding an attachment
> (BaseContentService.java:addAttachmentResource*).  At that level we could
> implement a check for file size.  If the file is 0kb we would throw an
> exception.
>
>  I was wondering if anyone had any better suggestions on where the problem
> should be tackled? Or maybe more importantly would a fix such as this at
> kernel level have any negative impact elsewhere?  Also are there any
> scenarios in which the user SHOULD be able to attach a 0kb file?  We would
> like to propose the most general fix possible as opposed to just adding
> another 'addAttachmentResource' function.
>
>  We considered suggesting changes at the Resource level but suspect this
> could cause problems with other interfaces / feeds of files which may happen
> contain an empty file.  This will be a much further reaching change and is
> likely an unnecessary one.
>
>
>  Thank You,
>
>  Adam York
> Teaching & Learning
> University of Michigan
> Information and Technology Services
> (734)615-2549
>
>
> _______________________________________________
> sakai-dev mailing listsakai-dev at collab.sakaiproject.orghttp://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110318/c158b97d/attachment.html