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

[David Horwitz]

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 <mailto: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 <tel:%28734%29615-2549>
>>
>>
>>     _______________________________________________
>>     sakai-dev mailing list
>>     sakai-dev at collab.sakaiproject.org  <mailto:sakai-dev at collab.sakaiproject.org>
>>     http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>>     TO UNSUBSCRIBE: send email tosakai-dev-unsubscribe at collab.sakaiproject.org  <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org>  with a subject of "unsubscribe"
>
>     _______________________________________________
>     sakai-dev mailing list
>     sakai-dev at collab.sakaiproject.org
>     <mailto: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
>     <mailto: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/5913cfa3/attachment.html