2009-07-03 09:13 AEST by Arthur Barrett - during "cvs update" cvs [server aborted]: cannot open : No such file or directory.

cvs [server aborted]: cannot open path/to/file/CVS/Entries.Extra: No such file or directory

2009-07-03 09:14 AEST by Arthur Barrett - Hi Richard,

Windows has a maximum PATH size which you have exceeded. 

In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters. A 
local path is structured in the following order: drive letter, colon, backslash, components separated by 
backslashes, and a terminating null character. For example, here is an example of the error in windows 
using the MD command:
d:
cd "D:\cvsbin\release builder\cvsnt\testcvs\richard\Change Requests\CR31\"
cd "Reporting Tool Release Pack\Source Code\"
cd "Colledia Reporting Tools\Colledia.PeriodicReportsService\bin\"
cd "Release\Colledia.PeriodicReportsService.publish"
md Colledia.PeriodicReportsService_1_0_0_0
The filename or extension is too long.



The actual point that you will exceed the MAX_PATH size varies with CVS Suite on things such as:
* the 'root' directory of the sandbox
  - ie: you get a longer path if you checkout into c:\a\ than if you checkout to c:\blah244toodoo\
* the 'temp' directory of the (windows) server
  - ie: you get a longer path if the server checks out to c:\t\ than if TEMP is c:\temp244toodoo\
* the 'root' of the repository on the (windows) server
  - ie: you get a longer path if the server repo is in c:\r\ than if the repo is in c:\repo244toodoo\


Note: he Windows API has many functions that also have Unicode versions to permit an extended-
length path for a maximum total path length of 32,767 characters, however for historical reasons there 
are not used universally in CVS Suite - ie: whilst CVS Suite does support Unicode some functions still 
use the 'old' calls during processing.

More technical information from Microsoft is available here:
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

Regards,


Arthur Barrett

2009-11-06 09:33 AEST by Arthur Barrett - I'd be very interested to know in 'real world' cases how widespread this issue 
is and in particular:

1. is there a particular toolchain more likely to create this (eg: Eclipse/Java)

2. is this more common as a client or server issue (anecdotal evidence 
indicates it's more often a client issue)

3. is this also a problem in svn/git on windows?  Is it already being 
addressed, or unlikely to be addressed?

4. can we determine if switching API's will have other positive or negative 
effects - eg: performance, compatibility with anivirus, etc etc

5. are we certain that MS are not going to address this in the CRT any time 
soon (MSVC 2010)?

6. should we combine this effort with a move towards asynchronous I/O 
(threaded) - I'm thinking more the client here than the server, but it's 
applicable to both.  Implementing asynchronous I/O would mean that CVSNT would 
no longer stop on the 'first' error - ie: 'cvs up a b c d' - if 'b' fails then 
currently CVSNT stops leaving a updated but not c or d - but with asynchronous 
IO both a and c could be updated before b fails and d aborted

7. does the Intel c++ compiler include its own crt - and if so would be resolved

2011-11-01 10:37 AEST by Arthur Barrett - Changed summary from:

during "cvs update" cvs [server aborted]: cannot open : No such file or directory

to:

during "cvs update" max server path length exceeded


This can also occur if the server is windows but the client is non-windows (and doesn't have the PATH 
limitation).  There are two areas where it will occur:
* repository:
  - PATH traverse in the repository
  - rewriting RCS files
* temp directory:
  - a copy of the checkout is placed here

So to fix the server we almost end up 'fixing' the client (because the server basically does a client 
checkout into temp then sends it to the client over the protocol).

There are potentially large impacts for the server admin: will the backup tools process these files?  If 
something goes wrong, how can you find these files, can you delete long path name temp folders that 
are leftover after a server crash etc etc.

2018-02-28 08:16 AEST by Arthur Barrett - Since we support l longer path/filenames in Linux, I'd be interested to know if setting the new 'long path' 
setting in windows 10 fixes this:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD).

see:
https://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx?
f=255&MSPPError=-2147217396#maxpath

If it does fix it, we could theoretically create a manifest for supporting versions of windows...