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.
Related
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?!
I recently switched my development machine from Windows XP to Windows 7 and since that switch, I have a problem with files permissions when I do operations with Tortoise SVN.
Example:
I Have two ASP.NET website set on my local IIS. Beta and Devlo. Beta is a check out of the branch I'm working on and Devlo is a check out of the Trunk.
I made some change on the Beta website and Check it in.
Then I made a merge to reintegrate the branch in the truck on the Devlo website, but I got this error when I test it :
Parser Error
Description: An error occurred during the parsing of a resource required to
service this request. Please review the following specific parse error details
and modify your source file appropriately.
Parser Error Message: Access to the path 'C:\[...]' is denied.
After investigation, I discovered that every file that was modified by the Tortoise SVN merge lost theirs file permission (Read, Read & Execute) for the users IUSE and IIS_IUSRS.
I could manually put them back, but this happen every time I perform an operation of this kind. Is there a way to keep those permissions unchanged by the SVN operation?
Update
Before the Merge, the file was inheriting is permission from the parent folder (has it's supposed to do.)
But not after the merge :
The original file (in the beta folder) was inheriting is permission from the parent folder.
Why the TortoiseSVN (explicitly?) block permission inheritance?
I had the same issue and fixed it with the help of this SO answer: https://stackoverflow.com/a/8993163/361831
The answer mentions that updated files are copied to a .svn/tmp directory which is located in the top level of your working copy (as of tortoiseSVN 1.7). This top level dir didn't have the IIS permissions so I guess they weren't inheriting during the copy. So I just set the IIS permissions to that top level dir and set to inherit, and that fixed the issue.
When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)
In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.
If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place. (Subversion doesn't change the permissions itself on Windows)
ANSWER: Locate your .svn directory for that project and fix the permissions with permissions needed by your project.
You should be able to set these permissions on the folder that contains the files and then let the files inherit these permissions, instead of explicitly setting the permissions on the files themselves.
TortoiseSVN may delete and create files instead of renaming. When a new file is created this way it will not have the original permissions, but it will inherit permissions from its container.
See also: Explicit vs. Inherited Permissions
Each permission that exists can be assigned one of two ways:
explicitly or by inheritance. For this reason, permissions are
referred to as explicit permissions and inherited permissions.
Explicit permissions are permissions that are set by default when the object is created, or by user action.
Inherited permissions are permissions that are given to an object because it is a child of a parent object.
Similar to the way rights are managed for groups of users, permissions
are best managed for containers of objects. Objects within the
container inherit all the access permissions in that container.
See also: TortoiseSVN - Deleting, Moving and Renaming
Since renames and moves are done as a delete followed by an add...
I had the same problem on both my Win7 64bit machines. I would check in code on one, go to the other, do a Tortoise SVN Update, and have to reset the permissions on the folder to let the parent folder's permissions propagate downwards.
I finally found this article, tried it, and two weeks later it seems to be holding up.
Open the Registry Editor (click Start > Run, type regedit, then press ENTER).
Locate the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
With the key selected, on the Edit menu, click Add Value, and then add the following registry value:
Value name: ForceCopyAclwithFile
Data type: DWORD
Value data: 1
Exit the Registry Editor.
http://kb.globalscape.com/KnowledgebaseArticle10473.aspx
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.
When I create or open a file in UNIX using O_CREAT flag, st_mtime,st_ctime and st_atime of the file changes. But when I create or open a file using O_TRUNC flag, only the st_mtime and st_ctime changes and not the st_atime.
From my understanding, st_atime changes when the file is accessed. When we open or create a file using O_TRUNC flag, are we not accessing the file?
This question is a bit old, but an answer for future generations at least...
From stat(2) man page (on a host with a linux 2.6.32 kernel):
The field st_atime is changed by file accesses, for example, by execve(2), mknod(2), pipe(2),
utime(2) and read(2) (of more than zero bytes). Other routines, like mmap(2), may or may not
update st_atime.
The field st_mtime is changed by file modifications, for example, by mknod(2), truncate(2),
utime(2) and write(2) (of more than zero bytes). Moreover, 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.
The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link
count, mode, etc.).
Exsits any way to modify the temporary folder path returned by System.IO.Path.GetTempPath() method?
My asp.net application run under iis 7.
Thanks
Presumably, you don't want to change the returned path (value), but change the actual path?
As you can see here, the value returned depends on a number of possible environmental variables. You'd need to change these to change the returned path.
I wonder why you want to change that, as no matter what path it is returned, your application uses it as a temp folder (where the files can be cleaned freely).
If your application does care the existence of the files, write them to your own temp folder, which means you should give up System.IO.Path.GetTempPath(). Many applications, even Microsoft's, use their own temp folders.
I don't think you should change any temp folder environment variables as that will affect other applications unnecessarily (though they should not care if they really treat the folder as a temp folder :)).