Community
Participate
Working Groups
I recently had to import a vendor library into CVS and while doing a check out using eclipse cvs it bombed out with the following error: <quote> ERROR: Checking out 'Netcool532' from CVS: Problem writing resource '/Netcool532/ilumos/lview/ws/gen/46:44'. : is an invalid character in resource name 46:44 </quote> The actual file name it is having trouble with is called: <code> findmerge.log.21-Nov-03.12:46:44 <code> The issue is related to wether ":" is legal under which file system. Under Linux and unix filesystems ":" is a legal character. Under Windows it is not. Can it be translated on the fly into unicode when downloading to Windows ? Today the cvs client on windows does not handle ":" gracefully and you end up witht he last few characters being displayed like for the above file name <code> 46:44 0 <code> could be transformed into <code> findmerge.log.21-Nov-03.12%3A46%3A44 <code> which is legal under windows and is the strategy used under linux apt-get for storing "dubious" file names, and perhaps it could be translated back on the fly on checkin ? Just my 0.02c
This is a restriction that comes from Paltform Core. Moving to Core for comment.
The restriction here is coming from the file system, not platform core. He is requesting that the checkout rename the file into a unicode escape sequence. I recommend closing as WONTFIX.
I agree with John. Assuming the file is there to be used by other files, changing the name will just break something else anyway.
Warning the user with a somewhat cryptic message isn't necessarily all that useful either. There are two issues. Firstly, the CVS view is incorrect on windows. You cannot see the true name of the file in the hierarchy as presented by eclipse. Try it yourself. This *is* a bug. Secondly, windows won't handle ":". That's fine, if you won't fix it, but DO NOT BOMB out the checkout process. All other files following the bad file name are NOT checked out; resulting in an incomplete checkout. You could: - prompt the user to rename the file locally - warn the user that the filename is incompatible and tell the user to have the admin rename the file - or not check out that one file but continue checkout for all the others that follow. ignoring the issue is sort of silly don't you think ? La la la, windows can't deal with it, so I won't gracefully either...
Unfortunately, CVS doesn't support the file rename or a partial checkout so really our only option is to fail. I guess we could be more grace on the failure though. Reopening.
hmm. I tried the checkout using the cvs client on cygwin and it just keeps going. Since I had our admin rename the file to use underscores I'm not altogether sure what it does and need some time to test it. If in doubt, do what cygwin cvs or wincvs would do. OK, so I set up a test with a different cvs using wincvs. wincvs does the following: <quote> *****CVS exited normally with code 0***** cvs checkout -P 3rdparty/test (in directory C:\) cvs server: Updating 3rdparty/test cvs checkout: cannot write 3rdparty/test/blah:blah:blah: Invalid argument U 3rdparty/test/test2 U 3rdparty/test/test3 *****CVS exited normally with code 0***** </quote> it keeps on going, even though it has problems with the first file. I would much rather the EclipseCVS was modified to do the same thing and simply reports the error, since I presume the write error is local to the client not the CVS protocol itself. That way an admin can then be called to do the real fix which is rename the file in the repository to a compatible naming strategy or attic the old file and readd the new filename. BTW, thanks for responding, I appreciate the effort.
The same applies to resources that end in dot. Unfortunately, it is too late to do anything in 3.0. Moving to 3.1.
I've also encountered something similar. An attempt to checkout Python CVS on windows fails, complaining about leading spaces in some of the Mac platform support filenames. For me, the major issue is that the checkout aborts, rather than that it can't do anything with that file. For portable code (e.g Python), some of the non-Windows files may have filenames that Windows can't handle. That's OK, since Python's own cross-platform support means the Windows build process won't try to use those files, anyway. (Although, NTFS copes with leading and trailing whitespace quite happily when working from the command line - Windows explorer will display files named that way, just don't try to rename them, since explorer will 'helpfully' strip the whitespace)
Fix released to HEAD
