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

[Savitha Prakash]

I would agree that modifications to not allow 0kb attachments should be done
at the tool level. Making a change in kernel, would need a through research
in very many places, need to think about all the consequences, and also will
need consensus from many.

+1 to making the change in the tool level.

Cheers,
Savitha

On Sat, Mar 19, 2011 at 6:53 AM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> +1 to doing this at a tool level only. Provide the API and let tools use
> it.
>
> cheers,
> Steve
>
>
>
>
> On 19/03/2011, at 7:22 PM, David Horwitz wrote:
>
>  The origional reason to add support for 0b files was for DAV support - its
> something that some DAV clients expect as they expect the store to operate
> as a Unix filesystem.
>
> So I would have a -1 to doing this at the add resource level. Specificaly
> for attachments is another matter. If a tool wishes to disallow 0kb files it
> should do so
>
> D
>
> On 03/18/2011 09:13 PM, Matthew Jones wrote:
>
> 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"
>>
>
>
> _______________________________________________
> 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"
>
>
>
> _______________________________________________
> 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"
>



-- 
Savitha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110321/45c7dbf4/attachment.html