How to search all archived file that exceeds 100MB in a particular BASE Clearcase VOB. In Unix file system, it is easy:
find . -type f -size +104857600c -exec ls -la {} \;
Would it be possible to search directly in the folder of the VOB in the file system without create a Clearcase view and modify the config spec?
If I have to create a Clearcase view, would it be possible to use the cleartool command find to search in the whole VOB.
As mentioned in this technote:
At present there is no size option available with the cleartool find command.
The decision was made by Product Management to exclude the requested feature from future upgrades and releases due to the significant architectural changes required to implement the solution.
So creating a view remains mandatory.
And you can either directly use the ClearCase Explorer:
Or use your regular Linux command in a dynamic view:
# find . -size +20480c -print
./vendor/Common/NT/work/toolset/make/cal.output
./vendor/Common/NT/work/toolset/make/paf.output
would it be possible to use the cleartool command find to search in the whole VOB.
"The whole VOB" as in "all possible versions"... not really, unless you try and find files in the extended pathnames of an MVFS dynamic view. I haven't tested that option so.
Related
I have to use ClearCase at work and the basic workflow requires me to do something like:
cleartool setview <view-tag-name>
view-tag-name is a dynamic view I might add. From what I've gathered this opens up a new shell that allows me to access files in /vobs/some/path that go through a mounted MVFS file system. However this second shell on top of the existing shell breaks my Emacs client - Emacs daemon cooperation. Moreover, in another SO answer someone was saying that he didn't bother with setview at all and so instead of accessing:
/vobs/some/path (from within a setview shell)
… he would access:
/view/view-tag-name/vobs/some/path (without using a setview shell)
I've experimented a little and it seems that all cleartool commands work the same way whether I am in /vobs/some/path (in a setview shell) or whether I am in /view/view-tag-name/vobs/some/path (in a plain shell).
So my questions are:
what's the difference between working in /vobs/some/path in a setview shell versus working in /view/view-tag-name/vobs/some/path in a plain shell?
what is the proper term to use when referring to the /view/view-tag-name directory?
why when I do ct lsview -l -properties -ful view-tag-name I don't see any reference to the /view/view-tag-name directory? Isn't this directory associated with the view?
what's the difference between working in /vobs/some/path in a setview shell versus working in /view/view-tag-name/vobs/some/path in a plain shell?
Do not use cleartool setview: As I explained before, the cleartool setview command opens a subshell in which commands are supposed to be run, which can be problematic.
Working in /view/view-tag-name/vobs/some/path means you remain in your main shell, with all its properties.
what is the proper term to use when referring to the /view/view-tag-name directory?
That references the full path view root folder (inside which you are mounting vobs and accessing versions based on the view config spec and its selection rules)
In /vobs/some/path, you can still see the view you are in with cleartool pwv ("path working view").
why when I do ct lsview -l -properties -ful view-tag-name I don't see any reference to the /view/view-tag-name directory?
You are seeing the property of the view, which will then be mounted in /view/view-tag-name (on Unix) or M:\view-tag-name on Windows.
Those properties make no assumption on the runtime usage of that view, they only display static metadata (like the view storage or the view type)
If your workflow was to start emacs and then set into a view from there, things will be strange indeed.
The only thing that setview does differently from startview is that it starts that chrooted shell. Only that shell, and its descendants, will see source code in /vobs/vobtag/... If you work in multiple "setview" shells (for multiple versions of your app to maintain, multiple phases, etc.), you would have multiple otherwise identical shells accessing different versions of the same files via apparently-identical paths.
One thing to be aware of when working with ClearCase is that directories are versioned too. As a result, files added in one view may not appear in the other view if:
They are based on different versions of the parent directory; or
The parent directory of the file added to source control hasn't been checked in yet.
Unless your build process requires VOB contents to be visible at /vobs/vobtag, I'd concur with #VonC about not using setview.
I can't really add anything to VonC's other comments.
I have a requirement to apply a default permission to files transferred into a specific folder in Unix. I did a look up on internet and found two ways. However, I can't use them for the reason mentioned:
1. umask
This command can only be used in user login level by mentioning it
in .bashrc / .profile file. Won't work for me because I want the
permissions to be applied regardless of the logged in user, and only
to a specific folder.
enter code here
2. setfacl
This command can only be used when the drive on which the folder is
located, is mounted with file access listing enabled. This won't for
me because I can't involve Unix system admins in this activity at my
workplace.
Please suggest if there's an alternate (and possibly a simple) way to achieve the solution for my requirement.
I have no knowledge of MIDES, but if your user is allowed to run cron, then a cron entry similar to the following:
/usr/bin/chmod /dir_name/*
E.g.
/usr/bin/chmod 750 /export/xfr/*
would run every minute and change the permissions of all files in your directory to what you want them to be.
It may not be exactly what you are asking for, because it will run on all files in that directory rather than just the ones transferred.
If you need it to only run on certain files within that directory, then you could use something like find to better define the files to act on. E.g.
/usr/bin/find -user -exec /usr/bin/chmod {} \;
E.g.
/usr/bin/find /export/xfr -user narayanf1 -exec /usr/bin/chmod 750 {} \;
would only change permissions on the files in /export/xfr owned by the user narayanf1.
man find
will give you further options on other options such as creation time, modification time, size, name etc.
Once you label file versions in a release, ideally you want to protect that code from inadvertant removal (please read everything before commenting). It is too easy to delete the code.
I know I can lock the label but the file versions attached to the label don't get automatically locked (you would have to create a perl script to do that?). You can lock an element but not an element version. Furthermore, once you lock an element, you can't check it out!!!!! STUPID. This stops future development! All I want to do is protect the code I developed (without copying it elsewhere for archive). A repository should protect the code you develop.
Of course, there is the protect command but that doesn't work in snapshot / web views.
Again, ideally you would want to lock all the element-versions in a release but still be able to continue development. The lack of this feature seems to be a gross oversight.
Any ideas? (if you have any perl scripts, please post)
It is too easy to delete the code.
It shouldn't be: the only way you will be removing that labelled version from a ClearCase VOB is through destructive commands like cleartool rmelem or cleartool rmver.
All you need to do is to have a (preop) trigger in place denying those commands for everybody (except a ClearCase admin).
Something along the lines of:
cleartool mktrtype -nc -all -ele -pre rmelem -nusers $nusers -exec \"$perl_cmd -e exit(1)\" NO_RMELEM\aim"
I would still recommend to lock the label anyway, in order to make sure it isn't moved to another version.
As in:
ct lock -nusers vobadm lbtype:FOO_LABEL#vob:/vobs/admin
But again, if rmver is denied, your (labelled) code is safe.
Actually, the OP was talking about rmname (the DEL) in ClearCase Explorer.
The fear is that if a file is deleted, and a label is moved, then one could ignore for a long time the deletion.
BUT a label should never be moved:
the label from a ClearCase UCM baseline is immutable (you cannot move it)
a label in base ClearCase should always be locked
I am working in a dynamic view in Unix platform. I need to hijack a file temporarily and cancel the hijacking later. But the command chmod +w filename is not working.
I get the message chmod: WARNING: can't change filename.
I can change the read-only attribute of the file from a snapshot view in windows.
Questions:
Is hijacking possible in a dynamic view? If yes, how?
Is there a cleartool command to cancel hijacking of a file?
One of the side-effects of a dynamic view is that ClearCase will control the attributes of the file you access to through the network, as opposed of a snapshot view (where everything is copied on your hard drive).
1/ Yes it is possible, even though it isn't really an "hijacked" state.
The dynamic equivalent is named "eclipsed": the idea is for a private file of the same name than a versioned one to take the place ("eclipsing") of the versioned file.
You simply make a copy of that file as a backup, and make that file invisible by not selecting it (type "cleartool edcs" anywhere within the dynamic view):
element /vob/path/to/file -none
Then you rename the backup copy, restoring its original name.
2/ to undo an eclipsed file, you simply move it or delete it.
The versionned file (eclipsed by the private one) is restored instantly.
See IBM article "About eclipsed files and ClearCase" for more.
Why not doing an unreserved checkout?
cleartool checkout -unreserved filename
I need to move multiple symlinks within a VOB in a dynamic view.
As described in my previous question, this is not as trivial as it sounds (to me), as the target path is saved relative to the link itself and not to the VOB root or anything like that. This wouldn't be a big issue, if ClearCase would adjust the path information in those links, but appearantly, it does not.
Details: Let's assume following folder structure:
/myVOB
/Originals
/LinksA
/SubDir
/LinksB
Then moving a link to the file myVOB/Originals/readme.txt that is located in myVOB/LinksB to myVOB/LinksA/SubDir will prevent the link to find its target, as it is looking for myVOB/LinksA/SubDir/../Originals/readme.txt.
Does anyone know if it is possible to tell ClearCase to adjust the paths when moving symlinks? Usually I would think this should be done out of the box, but one never knows with ClearCase... Nevertheless, perhaps someone could try to reproduce this and tell me if it succeeded or not, perhaps it's just a bug on my system?
Edit: OK, so it looks like moving relative symlinks is not supported out-of-the-box. Would I need to move a great number of symlinks, I'd be writing a script right now that took a number of files/directories and moved them to a new location. If it encountered a symlink (whose target may be a file or directory) it would not just call cleartool mv or whatever, but follow the procedure as posted by VonC.
But I don't, so I'll probably do this by hand. Perhaps someone already wrote such a script, then this would be the right place to promote it ;)
If you consider this technote on "How to Manage symbolic links in ClearCase interop, it seems that:
(even if you aren't in an interop environment, ie even if your Windows views and Vob server are both on Windows)
symlinks are using primary relative path
you must recreate them if the target path change.
How to change a VOB symbolic link path
The only way to revise a VOB symbolic link to a relative path is to create a new symbolic link:
Note: You cannot edit (revise) a VOB symbolic link if it has been created using an absolute path to utilize a relative path.
-Check out the directory
- Remove the old VOB link using the cleartool rmelem command
- Create a new link with the same name
Example:
cleartool ln -slink -nc ../../same_file_name.txt
Check in the directory
Notes:
It is recommended that you use relative VOB symbolic links instead of absolute symbolic links.
The absolute VOB symbolic link requires you to use absolute path names from the view-tag level, for example, \view-tag\VOB-tag\filename.
Hence, they are valid only in the view in which they were created.