On Feb 14 23:59, Eric Blake wrote:
> Corinna Vinschen redhat.com> writes:
> >
> > I guess trying my approach isn't the worst one, though. We should
> > use that as a start point for further experimenting, IMHO. I'll check
> > that in.
> >
>
> Checking win32.has_acls() and using GENERIC_WRITE
Corinna Vinschen redhat.com> writes:
>
> I guess trying my approach isn't the worst one, though. We should
> use that as a start point for further experimenting, IMHO. I'll check
> that in.
>
Checking win32.has_acls() and using GENERIC_WRITE caused a regression in utimes
(). The new upstream
Corinna Vinschen redhat.com> writes:
>
> That could be a result of the Cygwin internals. I assume that the
> CreateFile call requesting any write access fails on both filesystems.
> If you have a look into utimes, you see that Cygwin ignores this case:
>
> h = CreateFile()
> if ((h == INVAL
On Feb 10 23:43, Eric Blake wrote:
> Corinna Vinschen redhat.com> writes:
> > Anyway, can you please test on both drives how they behave if utime
> > uses FILE_WRITE_ATTRIBUTES vs. GENERIC_WRITE?
>
> Well, that was my first time ever building cygwin1.dll, but it went smoothly.
>
> As requested
Corinna Vinschen redhat.com> writes:
> Huh? It reports "NTFS" as filesystem? Now, *that's* weird. Especially
> since none of the usual NTFS attributes are set.
I was surprised, too.
>
> Anyway, can you please test on both drives how they behave if utime
> uses FILE_WRITE_ATTRIBUTES vs. GENER
On Feb 10 15:10, Eric Blake wrote:
> Corinna Vinschen redhat.com> writes:
> >
> > Hey, why do you give up so quickly? If it's not the one way, it might
> > be another one. For us unknowing folks which have no OS/2 box with
> > HPFS to mount, would you mind to run the below application on your N
Corinna Vinschen redhat.com> writes:
>
> Hey, why do you give up so quickly? If it's not the one way, it might
> be another one. For us unknowing folks which have no OS/2 box with
> HPFS to mount, would you mind to run the below application on your NT
> box and paste the output into the reply?
That looks like it should do the trick. I just ran this on a
samba mounted FS, and FILE_PERSISTENT_ACLS is
true, and it does support the touch using FILE_WRITE_ATTRIBUTES.
I have asked Andrew DeFaria to compile/run your test program
on his Clearcase volume, to see if it follows the same trend.
I
I would also like to send this to Andrew DeFaria, since he
seems to have access to a ClearCase volume he was having
problems with.
Andrew, could you compile and run the program below against
your Clearcase volume, and either return the results to
cygwin-patches@cygwin.com, or to me, and I'll po
On Feb 9 10:27, Mark Paulus wrote:
> I'm not exactly giving up. It's just that at this point it looks like
> the fix will not be trivial, and since my company will not endorse
> a Waiver, I'm limited in the scope of fixes I can provide. However,
> I am more than willing to provide any testing/de
I'm not exactly giving up. It's just that at this point it looks like
the fix will not be trivial, and since my company will not endorse
a Waiver, I'm limited in the scope of fixes I can provide. However,
I am more than willing to provide any testing/debugging services
that are needed. The other
On Feb 8 13:49, Yitzchak Scott-Thoennes wrote:
> On Tue, Feb 08, 2005 at 10:10:29AM +0100, Corinna Vinschen wrote:
> > Have a look into path.cc, fs_info::update (). Test the filesystem
> > name in fs_info::update and add a flag to fs_info which tells us that
> > FILE_WRITE_ATTRIBUTES is supported
On Feb 8 14:38, Mark Paulus wrote:
> Well, all I can say, is "That's Uuuugggllleeey".
>
> When I print fsname on the HPFS mounted volume,
> I get back '??SS'. What the heck is that??? Somehow,
> I'm guessing that's not something I want to be doing a
> string comparison on, for any kin
On Tue, Feb 08, 2005 at 10:10:29AM +0100, Corinna Vinschen wrote:
> On Feb 7 14:37, Mark Paulus wrote:
> > So, what it really seems to boil down to is
> > for those filesystems that support doing timestamp
> > updating via FILE_WRITE_ATTRIBUTES (NTFS systems)
> > we should use FILE_WRITE_ATTRIBU
Well, all I can say, is "That's Uuuugggllleeey".
When I print fsname on the HPFS mounted volume,
I get back '??SS'. What the heck is that??? Somehow,
I'm guessing that's not something I want to be doing a
string comparison on, for any kind of stability purpose.
Guess I'll live with no
On Feb 7 14:37, Mark Paulus wrote:
> So, what it really seems to boil down to is
> for those filesystems that support doing timestamp
> updating via FILE_WRITE_ATTRIBUTES (NTFS systems)
> we should use FILE_WRITE_ATTRIBUTES, and for those that
> don't (HPFS, etc), they should use GENERIC_WRITE?
So, what it really seems to boil down to is
for those filesystems that support doing timestamp
updating via FILE_WRITE_ATTRIBUTES (NTFS systems)
we should use FILE_WRITE_ATTRIBUTES, and for those that
don't (HPFS, etc), they should use GENERIC_WRITE?
Unfortunately, during my brief perusal of MSD
On Feb 7 09:34, Mark Paulus wrote:
> Attached is a patch that works to allow me to do a
> touch on my mounted HPFS filesystem. I'm not sure
> about clearcase, or others, but it works on HPFS and
> NTFS.
>
> * times.cc: Use GENERIC_WRITE instead of FILE_WRITE_ATTRIBUTES.
That's reverting
Attached is a patch that works to allow me to do a
touch on my mounted HPFS filesystem. I'm not sure
about clearcase, or others, but it works on HPFS and
NTFS.
* times.cc: Use GENERIC_WRITE instead of FILE_WRITE_ATTRIBUTES.
times.cc.patch
Description: Binary data
19 matches
Mail list logo
