Having a TCR against Samba in order to allow this (or any) fasttrack to be approved on the basis that the fasttrack is not the right solution but resolves a customer problem seems a bit strange to me.
If we agree that adding a system attribute is the appropriate solution, we should pursue that now. The fact that SAMFS would require a change to support system attributes shouldn't really have a bearing on selecting the appropriate architectural solution, and if that's a concern perhaps we can talk about that offline. Alan -- Rick Matthews wrote: > Darren, > > I agree with Alan's proposal that the existing system extended > attributes be expanded > to include "offline" or whatever the appropriate tag could be. This > would require a change > to SAM-QFS to support Solaris extended attributes in at least the case > of that flag (a SAM-QFS > project/case, I'd guess) and modifying the interfaces introduced in > PSARC/2007/315 to include > the newly defined flag. > This case appears to be asking to use existing interfaces of SAM-QFS > to cause the > Solaris provided samba to detect a condition that is causing the > described customer > problem, and mitigate it. The resultant FILE_ATTRIBUTE_OFFLINE within the > SMB_QUERY_FILE_BASIC_INFO appears to be standard (at least in the SNIA > document). > I would think that advise to the PAC about modifying SAM-QFS to at > least support > an system extended attribute for offline, and for some unknown group > to add that to > the existing system extended attributes would be an appropriate response. > In the mean time, I would think this case could be approved with a > TCR to modify > the version of Samba shipped by Sun when the architecturally > appropriate interfaces > (those using the existing infrastructure described in PSARC/2007/315) > exist in Sun > current and future HSM products. > I could help add this to the general opinion, or add it as a minority > opinion. > == > Rick > > On 07/ 9/09 04:33 AM, Darren J Moffat wrote: >> Alan.M.Wright wrote: >>> Providing this as a temporary solution to relieve a customer problem >>> is excellent. My disagreement is that it should be committed as a >>> long term solution for offline support when we already have a defined >>> system attribute mechanism that could be used to solve the problem >>> via libc. >> >> Given the above I'm derailing this case for the purpose of writing an >> opinion with Advice to fund the above mentioned project and to point >> out the issue of adding Solaris/Sun functionality to Samba with no >> planned match for the in kernel CIFS server. >> >> PSARC members please are you willing to vote based on the above our >> would you like to see draft opinion text first. I've marked the >> case as "waiting need vote" for now. >> >> Note that this is *derail* not *deny* (though depending on the vote >> it could be but I doubt it). >
