Re: [OpenAFS] Win32: Free space of readonly volumes

2013-01-24 Thread Tobias Doerffel
Hi Jeffrey,

thank you very much for your quick response!

2013/1/23 Jeffrey Altman jalt...@your-file-system.com:
 File a bug report against the application that is querying volume
 information for the root directory of a drive mapping instead of for the
 path that the application is actually interested in.

The problem is that this occasionally happens with the Windows
explorer (Win XP as well as Win 7) however we can't recognize a
pattern.


 As a work around for applications that cannot be fixed, use a drive
 letter mapping to the root of the volume you wish the application to access.

At our company for performance reasons we're using a readonly clone
for the project root volume which only contains submounts for each
project. Mounting each project volume on a different drive letter is
not an option for us. I still cannot fully understand why a RO volume
should report 0 bytes of free space. An application should be unable
to write to that volume because it is a readonly volume and not
because there's insufficient free space. The latter one should not
matter, because IMHO it is not related to the actual problem.
Otherwise you would have to report 100% quota usage for all RO volumes
as well.

Anyways, if there is no (and will not be an) option to configure the
mentioned behaviour, we have to remove the RO volume in order to
satisfy our complaining users ;-)

Best regards

Tobias
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


[OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.6.2 release candidate 3 available

2013-01-24 Thread Hartmut Reuter

You can't build openafs-1.6.2pre3 outside the source tree!

Build ends with

gcc  -O -I/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11/src/config
-I/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11/include
-I../../../src/libafsauthent -I.  -DAFS_PTHREAD_ENV -pthread -D_REENTRANT
-D_LARGEFILE64_SOURCE -c ../../../src/libafsauthent/../volser/vsutils.c
../../../src/libafsauthent/../volser/vsutils.c:44:20: fatal error: volser.h:
Datei oder Verzeichnis nicht gefunden
compilation terminated.
make[3]: *** [vsutils.o] Fehler 1
make[3]: Leaving directory
`/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11/src/libafsauthent'
make[2]: *** [libafsauthent] Fehler 2
make[2]: Leaving directory `/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11'
make[1]: *** [build] Fehler 2
make[1]: Leaving directory `/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11'
make: *** [all] Fehler 2


-Hartmut

Stephan Wiesand wrote:
 The OpenAFS 1.6 Release Managers announce that release candidate
 1.6.2pre3 has been tagged in the OpenAFS source repository, available
 at:
 
git://git.openafs.org/openafs.git
 
 as tag: openafs-stable-1_6_2pre3 .
 
 Source files and available binaries can be accessed via the web at:
 
http://www.openafs.org/release/openafs-1.6.2pre3.html
 
 or
 
http://dl.openafs.org/dl/candidate/1.6.2pre3/
 
 or via AFS at:
 
UNIX: /afs/grand.central.org/software/openafs/candidate/1.6.2pre3/
UNC: \\afs\grand.central.org\software\openafs\candidate\1.6.2pre3\
 
 Among many fixes and enhancements, this release candidate includes
 support for Linux kernels up to 3.7, OS X 10.8 and recent Solaris releases.
 
 This is believed to be very close to 1.6.2 final. The Kerberos related
 changes mentioned in the last announcement are not yet ready, and will
 probably be part of the next stable release.
 
 Please assist us by deploying this release and providing positive or
 negative feedback. Bug reports should be filed to openafs-b...@openafs.org .
 Reports of success should be sent to openafs-info@openafs.org .
 
 Paul Smeddle and Stephan Wiesand, 1.6 Branch Release Managers
 for the OpenAFS Release Team
 ___
 OpenAFS-announce mailing list
 openafs-annou...@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-announce
 


-- 
-
Hartmut Reuter  e-mail  reu...@rzg.mpg.de
phone+49-89-3299-1328
fax  +49-89-3299-1301
RZG (Rechenzentrum Garching)webhttp://www.rzg.mpg.de/~hwr
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut fuer Plasmaphysik (IPP)
-
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.6.2 release candidate 3 available

2013-01-24 Thread Derrick Brashear
gerrit 8945

On Thu, Jan 24, 2013 at 8:51 AM, Hartmut Reuter reu...@rzg.mpg.de wrote:

 You can't build openafs-1.6.2pre3 outside the source tree!

 Build ends with

 gcc  -O -I/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11/src/config
 -I/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11/include
 -I../../../src/libafsauthent -I.  -DAFS_PTHREAD_ENV -pthread -D_REENTRANT
 -D_LARGEFILE64_SOURCE -c ../../../src/libafsauthent/../volser/vsutils.c
 ../../../src/libafsauthent/../volser/vsutils.c:44:20: fatal error: volser.h:
 Datei oder Verzeichnis nicht gefunden
 compilation terminated.
 make[3]: *** [vsutils.o] Fehler 1
 make[3]: Leaving directory
 `/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11/src/libafsauthent'
 make[2]: *** [libafsauthent] Fehler 2
 make[2]: Leaving directory `/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11'
 make[1]: *** [build] Fehler 2
 make[1]: Leaving directory `/home/hwr/tarfiles/openafs-1.6.2pre3/amd64_sles11'
 make: *** [all] Fehler 2


 -Hartmut

 Stephan Wiesand wrote:
 The OpenAFS 1.6 Release Managers announce that release candidate
 1.6.2pre3 has been tagged in the OpenAFS source repository, available
 at:

git://git.openafs.org/openafs.git

 as tag: openafs-stable-1_6_2pre3 .

 Source files and available binaries can be accessed via the web at:

http://www.openafs.org/release/openafs-1.6.2pre3.html

 or

http://dl.openafs.org/dl/candidate/1.6.2pre3/

 or via AFS at:

UNIX: /afs/grand.central.org/software/openafs/candidate/1.6.2pre3/
UNC: \\afs\grand.central.org\software\openafs\candidate\1.6.2pre3\

 Among many fixes and enhancements, this release candidate includes
 support for Linux kernels up to 3.7, OS X 10.8 and recent Solaris releases.

 This is believed to be very close to 1.6.2 final. The Kerberos related
 changes mentioned in the last announcement are not yet ready, and will
 probably be part of the next stable release.

 Please assist us by deploying this release and providing positive or
 negative feedback. Bug reports should be filed to openafs-b...@openafs.org .
 Reports of success should be sent to openafs-info@openafs.org .

 Paul Smeddle and Stephan Wiesand, 1.6 Branch Release Managers
 for the OpenAFS Release Team
 ___
 OpenAFS-announce mailing list
 openafs-annou...@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-announce



 --
 -
 Hartmut Reuter  e-mail  reu...@rzg.mpg.de
 phone+49-89-3299-1328
 fax  +49-89-3299-1301
 RZG (Rechenzentrum Garching)webhttp://www.rzg.mpg.de/~hwr
 Computing Center of the Max-Planck-Gesellschaft (MPG) and the
 Institut fuer Plasmaphysik (IPP)
 -
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info




-- 
Derrick
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Win32: Free space of readonly volumes

2013-01-24 Thread Jeffrey Altman
On 1/23/2013 9:05 AM, Jeffrey Altman wrote:
 Tobias,
 
 File a bug report against the application that is querying volume
 information for the root directory of a drive mapping instead of for the
 path that the application is actually interested in.  The AFS redirector
 reports each volume change in the path as a reparse point.  It is up to
 the application to query for free space in the correct volume.  A
 readonly volume by definition has zero bytes free.
 
 As a work around for applications that cannot be fixed, use a drive
 letter mapping to the root of the volume you wish the application to access.
 
 Jeffrey Altman

In particular, when filing a bug report against an application suggest
that the application developer obtain the free space information using

  GetDiskFreeSpaceEx

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364937%28v=vs.85%29.aspx

where the input parameter, lpDirectoryName, is the directory to which
the application is interested in writing.   It should not be the root
directory of the path.

The older GetDiskFreeSpace function

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364935%28v=vs.85%29.aspx

requires that the lpRootPathName parameter be the root of the path.
GetDiskFreeSpace does not work correctly when there are Reparse Points
(NTFS Junctions, NTFS Symlinks, CIFS Referrals, AFS Mount Points, AFS
Symlinks, etc) and should no longer be used.

Jeffrey Altman




smime.p7s
Description: S/MIME Cryptographic Signature