On Fri, Apr 6, 2012 at 2:39 PM, Derrick Brashear wrote:
> On Fri, Apr 6, 2012 at 2:22 PM, Darren Patterson
> wrote:
>>
>> On Apr 6, 2012, at 11:16 AM, Derrick Brashear wrote:
>>
>> I can't speak for what he's running. I'm running CentOS 6 as my host,
>> and I built the RPMs you'll find on the 1.6
On 4/5/2012 9:08 AM, Jeffrey Altman wrote:
> As I said, the AFS redirector is reporting the over quota
> condition as part of the response to the CloseHandle() call.
> Explorer does not call FlushFile() before CloseHandle() knowing
> that CloseHandle() will flush the file to disk.
>
> I will think
On 4/11/2012 7:01 AM, James Bricknell wrote:
> Hopefully this is a quick and stupid question.
>
> I have Mac clients on the network who have data in deep folder
> structures with long filename paths, well in excess of the Windows
> 256(255) character limit, and they need to copy their data across
Hi Michael,
Thanks for the reply. The paths in use aren't as long as 32, 767 characters,
but the 32,767 limit cannot be utilised. NTFS does indeed allow for a maximum
limit of a path that is 32,767 characters in length, but the problem is caused
by the applications that access the file system.
Are you sure this is the problem?
According to Wikipedia, NTFS has max 255 characters in filename and max
32k characters in pathname. HFS+ has max 255 characters in filename and
unlimited path length. Do you really have such long paths (more than
32,767 characters!!!)?
Mit freundlichen Grüßen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-04-11 13:01, James Bricknell wrote:
> Hopefully this is a quick and stupid question.
>
>
>
> I have Mac clients on the network who have data in deep folder
> structures with long filename paths, well in excess of the Windows
> 256(255) cha
Hopefully this is a quick and stupid question.
I have Mac clients on the network who have data in deep folder structures with
long filename paths, well in excess of the Windows 256(255) character limit,
and they need to copy their data across onto a Windows 2008 R2 Server, which
obviously fails