UbuntuThis forum is for the discussion of Ubuntu Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
In my project, there is a requirement for adding one more attribute for file properties which keeps track of previous file copies(Copy history).
So how can we accomplish this?
can we add/store this information in inode structure?
please help me out
thanks in advance.
The responsibility for copying files happens at the application level, so it doesn't make sense to have the copy log information at the file system level.
If this requirement applies to only a single application, then you have to be creative about different ways in which you might keep track of file copies. It could be a database, or a hidden file associated with each data file, or meta data stored in the file itself.
It also depends on the purpose of the copy history; whether it is for security reasons, for documentation, or whatever (ie, the specification is vague).
Last edited by neonsignal; 02-03-2010 at 06:32 PM.
the main intension of this application is to detect plagiarism. When any A file content is copied to some B file then in the B file we must have information that it is copied from A. I am not yet sure about the implementation like whether a database or log file or in file properties itself. can u please suggest which would be the best way. And i was going through FUSE, how feasible it is to use fuse for my project. Please help me out as i am a beginner in Linux.
My point is that if a file is readable, then it can be copied. Even the cp copy program simply opens the file and copies the contents; this is not done by the file system. File systems just provide the means of reading and writing to files.
You could log every open of a file, but this can only tell you that the file was read, not where it was copied to.
If you have control over the application(s) that opens the file, then that is where the logging must be done.
In some commercial settings, digital signatures are used on files to assert authorship. However, this is in the context of non-repudiation of authorship, not of plagiarism (eg signing off test results).
You still need to think more about exactly what you are trying to achieve. Imagine that the contents of the files were on paper sheets, and that everyone owned a photocopier. How would you keep track of paper copies? In this analogy, the filing cabinet is the file system, and the photocopiers are the applications. Think about the design before worrying about how to implement it on a particular operating system.
Last edited by neonsignal; 02-04-2010 at 12:44 AM.
Our intention is to avoid file to file plagiarism, here paper or hardcopy don't come into picture. But in the initial stages what we wanted to do is keep track of cp command i.e, whenever cp command is used on a file the information about the source file(copied) is stored in the inode structure of the copying file. In file properties of every we want to provide an additional attribute called "Log" or "history" which gives the previously stored details.
So, we thought of writing some kernel procedure to store information about the copied file and call the procedure from cp command. Is this the correct approach if initially we concentrate on only cp command.
The paper example was just to get you thinking about design, by thinking about an analogous process.
You could modify the cp command (ie, create your own cp with some logging code). But there doesn't seem to be any good reason to store the log/history from inside the file system; why not just log it to a database?
Anyway there is no simple way to comprehensively monitor copying; you'd have to modify at least half the commands in the system - there are dozens if not hundreds of different ways of doing a copy. And there is nothing to stop a person using their own (unmodified) version of cp.
The design comes down to a number of factors:
* will users (maliciously) want to change the log?
* can the files be viewed by any user?
* how much control do you have over the applications that the user has access to? (for example, do they have shell access)
* does a modified version of a file count as plagiarism?
* will users ever become aware that the copying is being logged?
* what is the nature of the data being copied?
* are you wanting to monitor copying, or to figure out which copy was original?
* does a link to the original count as a copy?
and so on; that's just a few questions off the top of my head
The problem in the digital domain is that information can be very easily copied, and copied perfectly. The only thing you need in order to make a copy is to be able to view the data, but there is no magical connection between the source and the copy. So it is possible to log viewings of a file, but impossible to know if a copy of the view was made without radically controlling every tool that might be used to make a copy.
Last edited by neonsignal; 02-04-2010 at 04:36 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.