I couldn't seem to logon to the trac to report this. I'm working on windows (not linux as the chmod might suggest). zlib-0.5.0.0>runghc Setup.hs configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0 --libdir=..\..\haskell_packages --bindir=..\..\haskell_packages\bin Configuring zlib-0.5.0.0... zlib-0.5.0.0>runghc Setup.hs build Preprocessing library zlib-0.5.0.0... Building zlib-0.5.0.0... ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a zlib-0.5.0.0>runghc Setup.hs install Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: permission denied (Access is denied.) Cabal seesm to create certain things as read only. I can work around this by chmod a+w ..\ThirdParty\haskell_packages\zlib-0.5.0.0\ghc-6.10.1\include\* chmod a+w ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* rm ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* I suspect most people haven't tripped over this as once something is installed they don't tend to install it again. Dominic.
Dominic Steinitz
I couldn't seem to logon to the trac to report this. I'm working on windows (not linux as the chmod might suggest).
zlib-0.5.0.0>runghc Setup.hs configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0 --libdir=..\..\haskell_packages --bindir=..\..\haskell_packages\bin Configuring zlib-0.5.0.0...
zlib-0.5.0.0>runghc Setup.hs build Preprocessing library zlib-0.5.0.0... Building zlib-0.5.0.0... ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a
zlib-0.5.0.0>runghc Setup.hs install Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: permission denied (Access is denied.)
This couldn't be a umask issue, could it?
G.
--
Gregory Collins
On Tue, 2009-01-20 at 16:56 +0000, Dominic Steinitz wrote:
I couldn't seem to logon to the trac to report this.
The details are on the hackage trac front page: http://hackage.haskell.org/trac/hackage/ If you don't want to register an account you can use the guest account. User name is "guest" and password "haskell'" (note the apostrophe at the end).
I'm working on windows (not linux as the chmod might suggest).
XP or Vista?
zlib-0.5.0.0>runghc Setup.hs configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0 --libdir=..\..\haskell_packages --bindir=..\..\haskell_packages\bin Configuring zlib-0.5.0.0...
zlib-0.5.0.0>runghc Setup.hs build Preprocessing library zlib-0.5.0.0... Building zlib-0.5.0.0... ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a
zlib-0.5.0.0>runghc Setup.hs install Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: permission denied (Access is denied.)
Cabal seesm to create certain things as read only. I can work around this by
We use System.Directory.copyFile which copies the permissions from the original file to the destination file. Could you confirm that this is working correctly. Are the permissions of the source and destination files exactly the same? Was the source file created read-only?
chmod a+w ..\ThirdParty\haskell_packages\zlib-0.5.0.0\ghc-6.10.1\include\*
chmod a+w ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\*
rm ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\*
I suspect most people haven't tripped over this as once something is installed they don't tend to install it again.
This looks like: http://hackage.haskell.org/trac/hackage/ticket/454 But for every file not just .exe files. For .exe files Cabal does the permission copying itself. I do not understand why it just started occurring, since ghc-6.8 and 6.10 seem to have the same code for copyFile and copyPermissions. We'll need more help to understand and fix this one. I think the right solution will be that we do not copy permissions at all but either set permissions to precise values or do nothing and use defaults. On Unix we have a similar issue with umasks. Duncan
Duncan Coutts
The details are on the hackage trac front page: http://hackage.haskell.org/trac/hackage/ If you don't want to register an account you can use the guest account. User name is "guest" and password "haskell'" (note the apostrophe at the end).
I did try but got the following. Forbidden TICKET_CREATE privileges are required to perform this operation I believe there is some interaction between the proxy we use at work and the trac. Other users in our organisation have also had the same problem.
XP or Vista?
XP
Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: permission denied (Access is denied.)
Cabal seesm to create certain things as read only. I can work around this by
We use System.Directory.copyFile which copies the permissions from the original file to the destination file. Could you confirm that this is working correctly. Are the permissions of the source and destination files exactly the same? Was the source file created read-only?
haskell_packages is empty to start with and the package gets built successfully. Attributes are copied over successfully. The actual source files *are* read only as they are kept in our source control system which marks them this way for unchecked out files. Built files are read / write.
ls -ltr haskell_packages\doc\zlib-0.5.0.0 total 2 -r--r--r-- 1 user group 1327 Jan 21 11:37 LICENSE
When I rebuild the package *without* having cleaned out haskell_packages then I get the access error. I think this is because cabal (copyFile) doesn't want to overwrite a read only file even though the directory permissions should allow it to do so.
This looks like: http://hackage.haskell.org/trac/hackage/ticket/454
But for every file not just .exe files. For .exe files Cabal does the permission copying itself. I do not understand why it just started occurring, since ghc-6.8 and 6.10 seem to have the same code for copyFile and copyPermissions.
I don't seem to have the problem for binaries (because cabal builds them afresh with read / write permission) so I don't know if it's related or not (but it seems unlikely).
ls -ltr haskell_packages\bin total 18004 -rwxrwxrwx 1 user group 4066816 Jan 21 11:38 cabal.exe -rwxrwxrwx 1 user group 13649408 Jan 21 11:39 haddock.exe -rwxrwxrwx 1 user group 718336 Jan 21 11:39 HsColour.exe
We'll need more help to understand and fix this one. I think the right solution will be that we do not copy permissions at all but either set permissions to precise values or do nothing and use defaults. On Unix we
That seems the correct thing to do. Let me know if you need any more information. Dominic.
Hia Dominic, I've looked into this a bit. I think I may now be less confused. :-) On Wed, 2009-01-21 at 18:01 +0000, Dominic Steinitz wrote:
We use System.Directory.copyFile which copies the permissions from the original file to the destination file. Could you confirm that this is working correctly. Are the permissions of the source and destination files exactly the same? Was the source file created read-only?
haskell_packages is empty to start with and the package gets built successfully. Attributes are copied over successfully. The actual source files *are* read only as they are kept in our source control system which marks them this way for unchecked out files. Built files are read / write.
Ok, that's fine. It's as we expect.
ls -ltr haskell_packages\doc\zlib-0.5.0.0 total 2 -r--r--r-- 1 user group 1327 Jan 21 11:37 LICENSE
Ah! Is that the only file that is read-only? That makes sense since it's an original source file from your read-only source control system. The System.Directory.copyFile function does not copy permissions (though it does try to) but it does (unhelpfully) copy the read-only attribute.
When I rebuild the package *without* having cleaned out haskell_packages then I get the access error. I think this is because cabal (copyFile) doesn't want to overwrite a read only file even though the directory permissions should allow it to do so.
Yes. The windows MoveFile function does not let us move a file over a file that has the read-only attribute. It's an annoying interaction between the semantics of old DOS/FAT read-only attribute and new windows file permissions (ACLs). The solution I think, is never to copy the read-only attribute when installing files. It's thoroughly unhelpful. I've got a patch to do this which I shall push to Cabal HEAD shortly. If you have a moment to help me test that it would be much appreciated.
This looks like: http://hackage.haskell.org/trac/hackage/ticket/454
But for every file not just .exe files. For .exe files Cabal does the permission copying itself. I do not understand why it just started occurring, since ghc-6.8 and 6.10 seem to have the same code for copyFile and copyPermissions.
I don't seem to have the problem for binaries (because cabal builds them afresh with read / write permission) so I don't know if it's related or not (but it seems unlikely).
I think you're right that it's unrelated. Your problem is caused by Cabal copying the read-only attribute where as that ticket turns out to be more related to permissions (ACLs) and users and inherited permissions etc. Duncan
On Wed, 2009-01-28 at 13:13 +0000, Duncan Coutts wrote:
The solution I think, is never to copy the read-only attribute when installing files. It's thoroughly unhelpful. I've got a patch to do this which I shall push to Cabal HEAD shortly. If you have a moment to help me test that it would be much appreciated.
I've attached a darcs patch against the Cabal-1.6 branch (rather than the head branch). darcs get --partial http://darcs.haskell.org/cabal-branches/cabal-1.6/ If you or anyone else can test it on Windows that'd be great. I checked it by setting the read-only attribute on a LICENSE file and where previously the attribute would get copied (preventing further re-installs) it is now not copied. On Unix it should solve this problem: http://hackage.haskell.org/trac/hackage/ticket/93 Though I've not tested that yet. The patch for the 1.6 branch is fairly minimal and doesn't change any API. In Cabal HEAD I'll do it slightly differently so that the code is more consistent and comprehensible, but it involves api changes to exposed utility functions. Duncan
On Thu, 2009-01-29 at 11:43 +0000, Duncan Coutts wrote:
On Wed, 2009-01-28 at 13:13 +0000, Duncan Coutts wrote:
The solution I think, is never to copy the read-only attribute when installing files. It's thoroughly unhelpful. I've got a patch to do this which I shall push to Cabal HEAD shortly. If you have a moment to help me test that it would be much appreciated.
I've attached a darcs patch against the Cabal-1.6 branch (rather than the head branch).
darcs get --partial http://darcs.haskell.org/cabal-branches/cabal-1.6/
The patch is now in the 1.6 branch, along with a fix to make it work with other ghc versions.
If you or anyone else can test it on Windows that'd be great. I checked it by setting the read-only attribute on a LICENSE file and where previously the attribute would get copied (preventing further re-installs) it is now not copied.
On Unix it should solve this problem: http://hackage.haskell.org/trac/hackage/ticket/93 Though I've not tested that yet.
It appears to fix this problem too.
The patch for the 1.6 branch is fairly minimal and doesn't change any API. In Cabal HEAD I'll do it slightly differently so that the code is more consistent and comprehensible, but it involves api changes to exposed utility functions.
I've pushed these changes too now so it should also work in Cabal HEAD and with a saner api. Duncan
Duncan Coutts wrote:
Hia Dominic,
I've looked into this a bit. I think I may now be less confused. :-)
On Wed, 2009-01-21 at 18:01 +0000, Dominic Steinitz wrote:
ls -ltr haskell_packages\doc\zlib-0.5.0.0 total 2 -r--r--r-- 1 user group 1327 Jan 21 11:37 LICENSE
Ah! Is that the only file that is read-only? That makes sense since it's an original source file from your read-only source control system. The System.Directory.copyFile function does not copy permissions (though it does try to) but it does (unhelpfully) copy the read-only attribute.
It may not be but a lot of packages only have a LICENSE file. I'll have a look tomorrow.
When I rebuild the package *without* having cleaned out haskell_packages then I get the access error. I think this is because cabal (copyFile) doesn't want to overwrite a read only file even though the directory permissions should allow it to do so.
Yes. The windows MoveFile function does not let us move a file over a file that has the read-only attribute.
It's an annoying interaction between the semantics of old DOS/FAT read-only attribute and new windows file permissions (ACLs).
The solution I think, is never to copy the read-only attribute when installing files. It's thoroughly unhelpful. I've got a patch to do this which I shall push to Cabal HEAD shortly. If you have a moment to help me test that it would be much appreciated.
Thanks very much. I'll try it out tomorrow.
On Sun, 2009-02-01 at 13:47 +0000, Dominic Steinitz wrote:
Duncan Coutts wrote:
Hia Dominic,
I've looked into this a bit. I think I may now be less confused. :-)
On Wed, 2009-01-21 at 18:01 +0000, Dominic Steinitz wrote:
ls -ltr haskell_packages\doc\zlib-0.5.0.0 total 2 -r--r--r-- 1 user group 1327 Jan 21 11:37 LICENSE
Ah! Is that the only file that is read-only? That makes sense since it's an original source file from your read-only source control system. The System.Directory.copyFile function does not copy permissions (though it does try to) but it does (unhelpfully) copy the read-only attribute.
It may not be but a lot of packages only have a LICENSE file. I'll have a look tomorrow.
Sure, I didn't mean that because it's only a license file it's ok. It's just that it makes sense given that it's one of the only files copied direct from the sources directory (rather than generated during the build). It took me a while to work out what was actually going on (and to realise it was different from the other permissions problems people have reported on Windows).
The solution I think, is never to copy the read-only attribute when installing files. It's thoroughly unhelpful. I've got a patch to do this which I shall push to Cabal HEAD shortly. If you have a moment to help me test that it would be much appreciated.
Thanks very much. I'll try it out tomorrow.
Thanks. The fixes are now in Cabal HEAD and the Cabal-1.6 branch so use whichever is easier for you. Duncan
Duncan Coutts
On Sun, 2009-02-01 at 13:47 +0000, Dominic Steinitz wrote:
Duncan Coutts wrote:
Hia Dominic,
I've looked into this a bit. I think I may now be less confused.
On Wed, 2009-01-21 at 18:01 +0000, Dominic Steinitz wrote:
ls -ltr haskell_packages\doc\zlib-0.5.0.0 total 2 -r--r--r-- 1 user group 1327 Jan 21 11:37 LICENSE
Having installed darcs and beaten our proxy to allow darcs to "get", I installed the patched 1.6 version and all seems to work.
ls -ltr haskell_packages\doc\zlib-0.5.0.0 total 2 -rw-rw-rw- 1 user group 1327 Feb 5 13:29 LICENSE
I had to make the following change in CopyFile.hs before it would compile so maybe it needs a further slight tweak? setFileOrdinary = return () setFileExecutable = return () to setFileOrdinary _ = return () setFileExecutable _ = return () Many thanks for your help, Dominic.
On Thu, 2009-02-05 at 13:45 +0000, Dominic Steinitz wrote:
Having installed darcs and beaten our proxy to allow darcs to "get", I installed the patched 1.6 version and all seems to work.
ls -ltr haskell_packages\doc\zlib-0.5.0.0 total 2 -rw-rw-rw- 1 user group 1327 Feb 5 13:29 LICENSE
Great.
I had to make the following change in CopyFile.hs before it would compile so maybe it needs a further slight tweak?
setFileOrdinary = return () setFileExecutable = return ()
to
setFileOrdinary _ = return () setFileExecutable _ = return ()
Oops, thanks. Duncan
participants (3)
-
Dominic Steinitz -
Duncan Coutts -
Gregory Collins