I had a folder which was encrypted by encfs. It was in an ext4 partition. I decided to move it into another folder, because I had not enough space in that partition. The new partition was a compression-enabled zfs partition on another hard disk. During the move along with the destination folder 'td', another folder '.shutdowntd' was also created. I don't know why. I didn't created it. Maybe zfs itself created it. Maybe encfs manager did it. Last night I looked into it. I saw that the number of files in both directories is the same. I saw that for any file in the directory 'td' there is a file in directory '.shutdowntd'. File sizes were not exactly the same, but were nearly the same. When I deleted a file in one of them, the corresponding file in the other directory was also deleted! The names in the directory '.shutdowntd' were different and seemed to be hash-coded. My computer was on during the night. Today, I saw that the folder 'td' was removed and a zero-byte file with the same name was created! I restarted Ubuntu (16.04). Now I see that the file is changed back to a folder with the same name ('td') with no content. But the folder '.shutdowntd' still exists with the files in it. I can't justify this behavior and don't know why it happened. Essentially why '.shutdowntd' is created? Why 'td's' content is emptied?! How can I recover it? What's happening?!
Related
I have a question related to Artifactory Jfrog..
Is it safe to delete files in /var/opt/jfrog/artifactory/temp folder?
Taking up a lot of spaces
Thank you
The temp folder is generally safe to delete as Artifactory uses it as a staging area for various indices it creates and for other generated files.
take care with a folder called artifactory-uploads if its present - that is the staging area for ui-originated uploads so you might end up deleting a file that represents an upload in progress, so only delete old files from that location.
I am updating files in CVS. I put files that I needed to update in my unix folder.
Using cvs add, cvs commit - I was able to add new files to directory.
I was also able to update some from 1.1 to 1.2 using cvs update.
However I am unable to update the version for one file, getting this error:
cvs update filename.scr
cvs server: move away filename.scr; it is in the way
Any ideas how to solve this?
Do exactly what it says - remove filename.scr. CVS update won't overwrite the existing non-controlled copy of filename.scr.
in the cvs hidden sub folder check if the folder of that file is on the list of entries, if so you have to add it
To be specific, this means there's a file in the repository, and a matching file in your tree, but the file CVS/Entries doesn't mention it. That can fail either for the CVS/Entries file at the same level as the file it's complaining about, or if you do a recursive update, it can fail due to the directory not being listed in CVS/Entries at a higher level.
This happens often to me, and I don't know why; a perfectly good checkout starts to get these errors. If it is a missing directory, the easiest fix is to directly edit CVS/Entries, e.g. to add
D/Foo////
to Bar/CVS/Entries so that CVS knows it already owns Bar/Foo.
If it's missing a file, it's hard to regenerate the CVS/Entries line, so it's easiest to do as it says and delete the file.
I'm reading a text on Version 6 unix, and just learned about inodes. I have the following question:
Suppose I have a file in one directory and a link to the file somewhere else. Am I correct to say that, if I delete the file, the inode will still exist because the refcount is not 0? And does this mean that the file isn't really deleted while the link exists, and I can access the file through the inode number?
Yes, if the link is a hard link. No, if it's just a symbolic link.
A hard link is basically the same file being in more than one directory, with the same inode. Unlinking the file from one of its directories just reduces its reference count by one. It won't be deleted until it reaches zero.
A symbolic link has its own inode and redirects you to the other entry. A symbolic link will dangle if its target is removed. A symbolic link itself can be removed with no effect on the target file or directory.
File names are just entries in the directory tables pointing to somewhere in the disk. A hard link is just another name entry pointing to the same data. Any subsequent hard link is indistinguishable from the original file name entry.
So the answer is yes.
I used "touch" on a file, updating the file's timestamp but the parent directory's timestamp did not change. However, (as expected) when I created a new file within the parent directory, the directory's timestamp did change.
What criteria do UNIX-like operating systems (specifically AIX) use to determine when to update the timestamp of a directory?
The timestamp is updated when the data that represents the directory changes. A change in a subdirectory of directory D does not change anything in the representation of D because D only points to the subdirectory, not to what's inside it. On the other hand, creating a file in D changes the block of data on disk that represents D.
A directory's timestamp is changed when the Directory itself is changed. The directory contains, among other things, a list of the inodes of the files in the directory so when you change the content of the directory by adding or removing files then the Directories timestamp will be updated.
You can use the stat command to find the modified time, creation time etc of a file/directory.
Refer to https://linux.die.net/man/2/stat
The article states:
st_mtime of a directory is changed by the creation or deletion of files in that directory. The st_mtime field is not changed for changes in owner, group, hard link count, or mode.
A Directory is considered as changed when there is any Addition or Deletion of File/Directory inside it. If existing Files/Directories are just getting update than Parent Directory timestamp will not change.
I Downloaded the http://ftp.drupal.org/files/projects/nl-6.x-1.5.tar.gz file from Drupal Translations page. The readme file says to "Copy (merge) the content of this translation package into your Drupal installation root directory".
If i look at the package it has a few text files and a modules, profiles and themes folders. If I copy those in the root (so MAMP/sitename/) it overwrites a bunch of files (there are already modules and themes folders there ...) and whatever page I load on the site gives fatal errors.
Is it possible that on MAMP / Mac Unarchiver doesn't do copy/merge but actually Replaces the old modules folder with this new one?
What should happen, is that the relevant .po files are places in the folders where they should be. If things go wrong, what you'll end up having, would be a folder with all the .po's, in a nested set of folders.
In theory I guess it's possible to overwrite folders etc, but you would be opted to allow that first.
So you shouldn't be afraid that your entire Drupal install will be overwritten. You can just try to do the unpack and see what happens. Worst case, is that you'll need to place the files in the correct folders yourself.
I can't speak to Unarchiver, but if you're overwriting files then something's not behaving correctly. All the translation packs really do is add some additional files and folders (e.g. /modules/user/tranlsations/modules-user.nl.po to /modules/user).
My guess is that your whole /modules/user directory (along with all the others) is being replaced, rather than added to.
Have you tried merging the folders in Terminal? You should be able to merge these folders directly from tar. Comment back if you would like more detailed instructions on how to do that.