I was playing around with creation and detection of Evil Twins, and when I delivered a change that had a Evil twin I noticed my snapshot-view suddenly had the following file:
This file is not in source control, but I'm wondering how it was created and what a view-private file is ?
The content of the file is:
cleartool : cleartool: Error: Unable to access
".##\main\0/element-pname": No such file or directory. In Zeile:1
Zeichen:1
cleartool find . -directory -ver '!lbtype(NOTDEFINED)' -exec "clearto ...
CategoryInfo : NotSpecified: (cleartool: Erro...e or directory.:String) [], RemoteException
FullyQualifiedErrorId : NativeCommandError
So I guess it was created when I tried to find evil twins but had an error in my command. I'm just interested why ClearCase created this file in my view, instead of maybe logging the error or something similar ?
Has anyone ever noticed this behavior ?
A private file (in snapshot or dynamic view) is a file which is not tracked/versioned by ClearCase.
See here or here to find/list them.
In your case, it could have been created because of your script making a redirection error ( > null instead of > /dev/null). Only the latter would make sure stdout is not displayed (because redirected to /dev/null.
Same for Windows, where >NULL prevents any stdout to be displayed, as opposed to >null, which would create a file named 'null'
Related
I have a very strange error running the cleartool lsview command under UNIX (version 7.1.2.12).
The command works in general but for some users (!) it gives the following error message :
cleartool: Error: No matching entries found for view tag "user_*".
I encountered this error first in a Perl-script but it is reproducible on the command line as well. I try to do something like :
cleartool lsview user_\*
Where user is the user name. For most users (like myself) cleartool will list my views that start with my user name and are followed by an underscore.
For some other users the command will return a list with their views but in addition it will produce the error message mentioned above. My script obviously checks for ClearCase errors and stops working. If I left out the underscore (any underscores in the pattern!) the error message is gone.
Is there anything I need to be aware of when querying the views of a user? The IT told me to do :
cleartool lsview|grep "user_"
which would work without an error message but I want to understand why the error comes up.
Thanks for reading so far.
I always use a grep, but I just test in command line (on Windows). This works:
cleartool lsview prefix_*
In other word, I never had to escape the '*'. This doesn't work:
cleartool lsview prefix_\*
cleartool: Error: Invalid view tag: "prefix_\*".
It can depend on how the shell will interpret the '*', as in this similar bug.
Under Unix, you might want to avoid a premature interpretation of the '*' (wildcard expansion) with double-quotes:
cleartool lsview "prefix_*"
The OP user2606240 reports in the comments:
As soon as the _ is in the view name I get the error message.
As far as I understood the registry and registered views that should not be the case.
I think I'll just implement the grep after lsview and live with it.
In a dynamic ClearCase view on Windows 7, I've got a file with size 0 and name myproject.prj.$$$. I cannot open, delete, rename or modify that file. I'd prefer to delete the file, but when trying to delete it:
Windows Explorer shows the error message “Invalid MS-DOS function”.
cmd.exe’s del: “Incorrect function”.
ClearCase Explorer simply does nothing.
I've created a file with the same name at a different location, and was able to edit and delete that file without any issues - so I guess the file name is not the issue. The file first showed up after the computer had crashed. I'd prefer not to delete and recreate the view.
What can I do to delete this file?
It looks similar to "Delete of view private file fails with error: Cannot find the specified file":
Cause
The view-private file has been moved or deleted from the view storage within the .s directory.
The view database is still aware of the file and is out of sync with the source container.
Note: The most common reason of this occurrence is due to Virus Scanning. The Virus Scanner is configured to either move a file suspected of a virus to quarantine or is configured to delete the file.
Solution 1
Remove and recreate the view.
Solution 2
If removal of the view is not an option, then synchronize the view database and the source container
The Example below is quite complete, but the OP Martin mentions in the comments:
It was not necessary to run the commands:
The mvfs log already contained the name of the missing file several times.
After creating an empty file at the "view storage container path", the file in the view could be deleted.
Example
The view storage container 800011174be29f22Paul.txt of the file Paul.txt was deleted.
M:\niewandt_view5\rn-robin>mvfsstorage Paul.txt
C:\ccstg_c\views\niewandt_view5.vws\.s\00007\800011174be29f22Paul.txt
This is the expected result although the file is not there anymore.
Now we flush the mvfs cache:
M:\niewandt_view5\rn-robin>mvfscache -f mnode
And run the mvfsstorage command again:
M:\niewandt_view5\rn-robin>mvfsstorage Paul.txt
mvfsstorage: Error: Paul.txt - can't fetch cleartext
Now we have a problem to identify which storage container is missing.
Trying to open the file gives:
---------------------------
Editor
---------------------------
Invalid Function.
---------------------------
OK
---------------------------
If we try to delete the file, it is reporting:
---------------------------
Error deleting file or folder
---------------------------
Paul can not be deleted: Invalid MS-DOS function.
---------------------------
OK
---------------------------
To find the view storage container path for that file you need to look in the mvfs log.
The mvfs log is showing:
{89 pid/tid 139400000cf0/883b7838eb6b63d0} cleartext lookup view=niewandt_view5 vob=\rn-robin dbid=0x80001117 - No such file or directory
{90 pid/tid 139400000cf0/883b7838eb6b63d0} cleartext pname= \Device\HarddiskVolume1\ccstg_c\views\niewandt_view5.vws\.s\00007\800011174be29f22Paul.txt
The "\Device\HarddiskVolume1" location can be found on the view properties 'advanced' tab, "Host path" in ClearCase Explorer
I faced this problem recently in windows environment.
*
(Caution : proceed if you are okay to delete local view-private
file which is corrupted and no data of that file can be retrieved)
*
My case was similar to above and was getting the following errors -
1. Windows Explorer shows the error message “Invalid MS-DOS function”.
2. cmd.exe’s del: “Incorrect function”.
I found mvfs log path by typing mvfslog in command prompt and that would output following details
Log priority: error
irpops mask: 0x00000000
vops mask: 0x00000000
vfsops mask: 0x00000000
xops mask: 0x00000000
traps mask: 0x00000000
Kernel logfile: "C:\mvfslogs\20191205.log"
Now open the log file from above path
"C:\mvfslogs\20191205.log"
So if you have got incorrect function recently, then that would be the last data logged as error in above log file.
Opening the log file and observe at the end of file, it reads something similar to below-
line #(last-1) - mvfs: Error: ....da..da..da...da... - No such file or directory
line #(last) - mvfs: Error: ....da...da...da...da... \your_container_location\..da..\..da..\..da..your_view_name.vws\.s\00037\800001765bf06476cc3080a
So that last word in above path(800001765bf06476cc3080a) is you actual file reference of your file in your_container_location. (Some times it might read as 800001765bf06476cc3080ayour_file_name.extension).
So now what is happening is
it is looking for your file reference 800001765bf06476cc3080a in
your_container_location path
(\your_container_location..da....da....da..your_view_name.vws.s\00037)
but it is not found(As data is not synchronized between your local
view and your_container_location).
So now all is required is
Step 1-to create a file named as 800001765bf06476cc3080a (as per your file name) in \your_container_location\..da..\..da..\..da..your_view_name.vws\.s\00037
Step 2-refresh your local view.
Step 3-Delete the file.
Now that the file should be able to delete permanently. And you can reuse your view.
I am facing a following issue while adding a file to clearcase (UCM)
---------------------------
Rational ClearCase Explorer
---------------------------
Error adding 'M:\Myviename\Myvob\Myproj\Implementation\DataSource\Deployment\BOM\SupportFiles\Service.config' to source control.
Created branch "Tm6-Proj-Dev2" from M:\Myviename\Myvob\Myproj\Implementation\DataSource\Deployment\BOM\SupportFiles\Service.config' version "\main\0".
Type manager "text_file_delta" failed create_version operation.
I tried rebase and deleted and added the file again. But facing the same. Why this occured and how to solve it?
You will find all the know cases for this error message in this technote "Knowledge Collection: Type manager <text_file_delta> failed create_version operation"
Type manager size limitation - File too large
Text files that contain binary data - Contains a '\000'
Line exceeding 8000 bytes
Corrupt source container - not the highest on its branch
The main cause is a content incompatible with a text file (line too long, or binary content).
The OP Samselvaprabu adds:
Our IT guys used the following command "chtype Compressed_file".
After that it allowed to check-in.
As they did it in my collegue system, I was not able to ask what does this mean and how it solved the issue?
It does solve the issue (and it has nothing to do with UCM): since the text_manager doesn't recognized the content of the file as text (as illustrated, for instance, in this technote), you need to instruct ClearCase to treat it as binary content.
cleartool chtype compressed_file <filename>
Pro: it allows for checkin/checkouts
Cons: you won't be able to "compare with previous version" anymore.
You might need to instruct that compressed_file to be always copied over instead of merged (see "Clearcase UCM is trying to merge pdf files")
For certain set of files, you could also modify the magic file to automate that process: see "Check in to ClearCase fails".
Which type of view are you using ? Static(Snapshot) or Dynamic ?
check if file is already there on the main.
If the file is already there on main (which means file is Versioned file) then before editing you should check-out file and then after making changes you need to check in.
If you are using versioned file and you if made changes to this versioned file then it will be a hijacked file, (you will see red+green mark for on the file in clear case explorer).
Try out once.
I am trying to add a file into ClearCase, but I am getting the following error:
Error adding 'C:\PATH\file.dbc' to source control.
Changed Protection on "C:\PATH\file.dbc".
Created branch "C:\PATH\file.dbc" version "\main\0".
Type manager "text_file_delta" failed create_version operation.
Checked the following:
There are lines that have over 8000 characters and they must stay that way, so it can not use the "text_file_delta" as the type manager. I changed the type of one file to "compressed_file" and I was able to check it in.
I tried to add dbc compressed_file -name "*.[dD][bB][cC]" ; to the default.magic file. Then, I tried to check it with ct file test.dbc and it said that it is a compressed_file, but when I try to add an actual .dbc file to source control, it still gives me the error about the "text_file_delta" failing.
Is there something that I am missing with this? Maybe I put the line in the wrong part of the default.magic file?
Note: the only default.magic file that I am able to find is on the server side, is this correct? (I would rather it check here instead of everyone having to make one on their client.)
Make sure the default.magic file is taken into account, and is in the right directory, as mentioned in "About the ClearCase Magic file".
Make sure you did add the new rule in the right place in that magic file: see "How file types are determined when creating a new element"
Note: This is the first section in the default.magic file.
Example:
# Match by name without examining data
core file : -name "core" ;
compressed_file : -name "*.[nN][eE][wW]";
Note: The new file-typing rule that you add must come before the following line in the magic file:
text_file : -printable ;
compressed_file : !-printable ;
Use a personal magic file rather than modifying the default one:
Caution: It is highly recommended that you not modify the default.magic file directly as the next time an upgrade is performed, a new default.magic file will be created and your changes will be lost.
Creating a personal magic file with a name that is alphabetically before the "d" in the default.magic file name (such as cc.magic) will allow ClearCase to parse this file before the default.
It is better to create a personal magic file and possibly setting the MAGIC_PATH variable instead.
So I'm writing a script at work where I have to go through all the projects in a ClearCase vob, look for a file and parse some info from said file.
Naturally, I wouldn't want to load every single project so I'm using cleartool to retrieve the unloaded files.
First, I'm using the find command to locate the files. This was my first attempt:
root>cleartool find C:/viewpath -name file.txt -version "lbtype(Version-label)" -print -nr
Viewpath is the path to the project where I'm currently looking for the file. The file I'm looking for is file.txt on the version specified by Version-label.
This gave me no result whatsoever, even though I knew file.txt existed on that version.
I figured out it was looking through an old version of the directory, the latest on the main-branch, which was before file.txt was added to the directory. I tried this instead:
root>cleartool find C:/viewpath##/Version-label -name file.txt -version "lbtype(Version-label)" -print -nr
And got this result, which was what I was looking for
C:/viewpath\file.txt##\main\branch\41
So now that I knew where I could find the file I tried to get it.
root>cleartool get -to savepath C:/viewpath\file.txt##\main\branch\41
Which gave me this result
cleartool: Error: "C:/viewpath\file.txt##\main\branch\41" does not exist, or is not a ClearCase version, or is a checked out version which was removed.
Also tried
root>cleartool get -to savepath C:/viewpath\file.txt##/Version-label
With the same result
I can get files added to the directory when it was still on the main-branch, so it is still searching through the directory on the main-branch, where file.txt is nowhere to be found.
How do I tell it to look through a version of the directory from after it was branched from main?
I would really recommend for you to try those same commands in a dynamic view.
As illustrated here, a dynamic view gives you access to extended path (the file##/branch/version syntax), which means command like get will work.
You have in this question an example of search (cleartool find) using extended paths.
As explained in "In ClearCase, how can I view old version of a file in a static view, from the command line?", you can browse (as in 'change directory to') the various extended paths of a file in a dynamic view.