On Nov 3 15:18, Warren Young wrote:
> On Oct 26, 2015, at 5:15 AM, Corinna Vinschen wrote:
> >
> > On Oct 23 16:15, Warren Young wrote:
> >> On Oct 23, 2015, at 8:30 AM, Jeffrey Altman wrote:
> >>> While Apple's design choices do not fit with the expectations of Cygwin
> >>> they are not
On Oct 26, 2015, at 5:15 AM, Corinna Vinschen wrote:
>
> On Oct 23 16:15, Warren Young wrote:
>> On Oct 23, 2015, at 8:30 AM, Jeffrey Altman wrote:
>>> While Apple's design choices do not fit with the expectations of Cygwin
>>> they are not necessarily wrong.
>>
>> So, should I send Apple this
Hi Jeffrey,
On Oct 23 10:30, Jeffrey Altman wrote:
> Lets discuss what is going on in this particular case. Apple
> constructs their file namespace as the machine name representing a
> virtual directory containing mount points to partitions and end user
> folders.
> [...]
> Apple's SMB file
On Oct 23 16:15, Warren Young wrote:
> On Oct 23, 2015, at 8:30 AM, Jeffrey Altman
> wrote:
> > While Apple's design choices do not fit with the expectations of Cygwin
> > they are not necessarily wrong.
>
> So, should I send Apple this code, or not?
>
>
On Oct 22 12:34, Warren Young wrote:
> On Oct 22, 2015, at 2:34 AM, Corinna Vinschen wrote:
> >
> > On Oct 21 11:26, Warren Young wrote:
> >> On Oct 21, 2015, at 10:22 AM, Corinna Vinschen wrote:
> >>>
> >>> On Oct 21 09:52, Warren Young wrote:
>
> I mean, I know how to snag a stream
In this thread there appears to be a small amount of misunderstanding of
what a reparse point is and how it should be used.
A reparse point can be thought of as a special form of extended
attribute on a file system object (directory or file) that can stored a
single {tag-value, opaque-data} pair.
Greetings, Warren Young!
>> Apple should have registered with Microsoft their own reparse point tag.
>> Instead they broke the rules and used Microsoft's
>> IO_REPARSE_TAG_MOUNT_POINT
> If Apple uses their own tags, wouldn’t that cause the Windows SMB client to
> be unable to understand Unix
On Oct 23, 2015, at 4:04 PM, Warren Young wrote:
>
> I’ve made the suggested changes to the program, here:
>
> http://pastebin.com/uZdDZPgi
By the way, if you look at scream_and_die() and wonder why I’ve badly
overcomplicated it, it’s because a previous version presented a printf-like
On Oct 23, 2015, at 3:20 AM, Corinna Vinschen wrote:
>
> Well, it was *you* asking "How could we prove that the problem is the
> Apple SMB server?" I was just trying to help. If that's not desired,
> I don't have to.
I shouldn’t have suggested attacking the problem at the SMB protocol layer to
On Oct 23, 2015, at 8:30 AM, Jeffrey Altman
wrote:
>
> In this thread there appears to be a small amount of misunderstanding of
> what a reparse point is and how it should be used.
Thank you for clearing all of this up. It was a fascinating read.
> the Apple SMB
On Oct 21 11:26, Warren Young wrote:
> On Oct 21, 2015, at 10:22 AM, Corinna Vinschen wrote:
> >
> > On Oct 21 09:52, Warren Young wrote:
> >>
> >> I mean, I know how to snag a stream of SMB packets with Wireshark, but
> >> I don’t know what I’d be looking for in the dump.
> >
> > Me neither,
On Oct 22, 2015, at 2:34 AM, Corinna Vinschen wrote:
>
> On Oct 21 11:26, Warren Young wrote:
>> On Oct 21, 2015, at 10:22 AM, Corinna Vinschen wrote:
>>>
>>> On Oct 21 09:52, Warren Young wrote:
I mean, I know how to snag a stream of SMB packets with Wireshark, but
I don’t know
On Oct 21 16:03, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
Your mailer is STILL breaking the history, btw. Could you reconfigure
so the "blah wrote:" header is preserved for each mail in the thread you
still quote? Thanks.
> > On Oct 21 15:33, Andrey Repin wrote:
>
> >> Windows does
On Oct 21 09:52, Warren Young wrote:
> On Oct 21, 2015, at 4:03 AM, Corinna Vinschen wrote:
> >
> > The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function
> > to fetch the reparse data it's no reparse point anymore? How dumb is
> > that?
> >
> > I can't reproduce this bug with
On Oct 21, 2015, at 4:03 AM, Corinna Vinschen wrote:
>
> The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function
> to fetch the reparse data it's no reparse point anymore? How dumb is
> that?
>
> I can't reproduce this bug with my Samba drives, but it's not actually a
> bug in
On Oct 21, 2015, at 10:22 AM, Corinna Vinschen wrote:
>
> On Oct 21 09:52, Warren Young wrote:
>>
>> I mean, I know how to snag a stream of SMB packets with Wireshark, but
>> I don’t know what I’d be looking for in the dump.
>
> Me neither, the Samba guys might be able to help there, perhaps.
Greetings, Corinna Vinschen!
> On Oct 21 15:33, Andrey Repin wrote:
>> Windows does not allow for reparse points to networked locations.
>> Symlinks all right, directory junctions no.
> Fine, but then the question is, why is the FILE_ATTRIBUTE_REPARSE_POINT
> flag set in the first place?
May
On Sep 14 14:34, Warren Young wrote:
> On Sep 12, 2015, at 11:14 AM, Nem W Schlecht wrote:
> >
> > The only thing I can think of is that the 2nd drive is >2TB.
>
> The same thing happens here with a 3.1 TB Fusion drive and a 500 GB external
> drive, so no, I don’t think the
Greetings, Corinna Vinschen!
>> > The only thing I can think of is that the 2nd drive is >2TB.
>>
>> The same thing happens here with a 3.1 TB Fusion drive and a 500 GB external
>> drive, so no, I don’t think the volume size is the real issue.
>>
>> I assume you are seeing the same thing that
On Oct 21 15:33, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
Your mailer is breaking the history, btw. Could you reconfigure so the
"blah wrote:" header is preserved for each mail in the thread you still
quote? Thanks.
> > Probably because of the above
>
> >
Greetings, Brian Inglis!
>> > Windows Explorer drive mappings are not visible from cmd or mintty/bash
>> > windows, but "net use x: \\live.sysinternals.com\tools" mappings are
>> > visible
>> > from separate cmd and mintty/bash windows as drive X: or /cygdrive/x, but
>> > x:\ is not accessible
Greetings, Brian Inglis!
> $ ls $(cygpath '\\live.sysinternals.com\tools\') # works - list contents
> About_This_Site.txt ctrl2cap.amd.sys* Eula.txt
> ...
> $ ls `cygpath '\\live.sysinternals.com\tools\'` # fails - should be same as
> above 2
> ls: cannot access
Andrey Repin yandex.ru> writes:
>
> Greetings, Brian Inglis!
>
> > $ ls $(cygpath '\\live.sysinternals.com\tools\') # works - list contents
> > About_This_Site.txt ctrl2cap.amd.sys* Eula.txt
> > ...
> > $ ls `cygpath '\\live.sysinternals.com\tools\'` # fails - should be same as
> > above 2
Warren Young etr-usa.com> writes:
> On Sep 16, 2015, at 7:39 AM, Nem W Schlecht gmail.com> wrote:
> > I would think if it was an issue with Mac's SMB implementation, then
> > *Windows* would also have some sort of issues with it. But it shows
> > up fine on Windows, I would assume it should
On Tue, Sep 15, 2015 at 6:21 PM, Warren Young wrote:
> On Sep 15, 2015, at 9:14 AM, Nem W Schlecht wrote:
>>
>> I'm going to be spinning up an Ubuntu box in the next few days that
>> will have a 5TB drive in it as well, so I'll be able to test to see if
>> the
On Sep 16, 2015, at 7:39 AM, Nem W Schlecht wrote:
>
> I would think if it was an issue with Mac's SMB implementation, then
> *Windows* would also have some sort of issues with it. But it shows
> up fine on Windows, I would assume it should show fine in Cygwin as
> well.
More
Greetings, Warren Young!
>> I'm going to be spinning up an Ubuntu box in the next few days that
>> will have a 5TB drive in it as well, so I'll be able to test to see if
>> the source OS (and/or version of SMB server) makes a difference.
> Good.
> Please test by exporting the filesystem root,
On Sep 14, 2015, at 9:46 PM, Andrey Repin wrote:
>
>>> The only thing I can think of is that the 2nd drive is >2TB.
>
>> The same thing happens here with a 3.1 TB Fusion drive and a 500 GB
>> external drive…
[snip]
>> Why errno 5 from path_conv?
>
> That's an interesting
On Sep 15, 2015, at 9:14 AM, Nem W Schlecht wrote:
>
> I'm going to be spinning up an Ubuntu box in the next few days that
> will have a 5TB drive in it as well, so I'll be able to test to see if
> the source OS (and/or version of SMB server) makes a difference.
Good.
Please
I'm going to be spinning up an Ubuntu box in the next few days that
will have a 5TB drive in it as well, so I'll be able to test to see if
the source OS (and/or version of SMB server) makes a difference.
I did an strace on '/bin/ls /cygdrive/t' on my host and saw almost the
exact same thing
On Sep 12, 2015, at 11:14 AM, Nem W Schlecht wrote:
>
> The only thing I can think of is that the 2nd drive is >2TB.
The same thing happens here with a 3.1 TB Fusion drive and a 500 GB external
drive, so no, I don’t think the volume size is the real issue.
I assume you are
Greetings, Warren Young!
>> The only thing I can think of is that the 2nd drive is >2TB.
> The same thing happens here with a 3.1 TB Fusion drive and a 500 GB
> external drive, so no, I don’t think the volume size is the real issue.
> I assume you are seeing the same thing that I am, that
I have 2 filesystem shares from a Mac that I'm mapping on Windows 7 as
my 'S' and 'T' drives. On the Mac, both directories are owned by the
same user/group and shared the same. One drive is 80GB (S) and the
other drive is 3TB (T). I can access /cydrive/s just fine. But
/cygdrive/t shows up
33 matches
Mail list logo