LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Ubuntu (https://www.linuxquestions.org/questions/ubuntu-63/)
-   -   How to add new attribute to the inode structure (https://www.linuxquestions.org/questions/ubuntu-63/how-to-add-new-attribute-to-the-inode-structure-786771/)

ramyayella 02-03-2010 03:35 PM

How to add new attribute to the inode structure
 
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.

neonsignal 02-03-2010 06:28 PM

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).

ramyayella 02-04-2010 12:09 AM

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.

Thanks in advance

neonsignal 02-04-2010 12:43 AM

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.

ramyayella 02-04-2010 02:14 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.

neonsignal 02-04-2010 04:33 AM

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.


All times are GMT -5. The time now is 03:38 PM.