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

[Steve Swinsburg]

+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 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"
>> 
>> 
>> _______________________________________________
>> 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"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110319/a79954ba/attachment.html