Can we add metadata to unlink/remove a file after x-time automatically. That is system automatically removes that file, if it finds that particular metadata attached with that file
Note- file can be present at any location, and user may move that file anywhere on their system, but based on that metadata file should get deleted(i.e system should call unlink/remove) for that file.
Is there a cocoa/objective-c/c++ api to set such metadata/attributes of a file?
The main point is i am creating an application through which i am providing some trial files to the user, and those files are also usable by other application which recognises them. After trial expiry, i want to delete those files, but user can always move my files to a different location and use them forever, how to protect those files from permanent use?
No, there is no built-in mechanism to auto-delete a file based on some metadata.
You could add the feature yourself, with an accompanying agent that would trawl for files with the metadata and delete them when the time came.
If you are doing this for good housekeeping you can follow #Petesh answer.
If you are doing this because you really want those files gone then no. The user could move the file to a USB stick and remove it, or edit the metadata, etc.
Your earlier question "Completely restricting all types of access to a folder" seems to addressing the same issue and the suggestions are the same as given there - use encryption or implement your own file system.
E.g. have a special "trial file" format which is the same as the ordinary format - which is readable by other apps - but encrypted and includes an expiry date. Your app then decrypts the file, checks the date, and either does its thing or reports to the user the file is out of date.
The system isn't unbreakable, but its a reasonable barrier - easy for you to do, too hard for the average user to break.
Related
I tried to create file that will not be deletable and read only. (Its an exe, so maybe I need execute too.)
I tried to achieve it with this:
SetFileAttributes(My_File_Path,FILE_ATTRIBUTE_READONLY);
but it only protected against writes (it lets read it but not write to it), while against delete it's doing nothing, even though according to MSDN it's supposed to protect from deletion also:
A file that is read-only. Applications can read the file, but cannot write to it or delete it. This attribute is not honored on directories. For more information, see "You cannot view or change the Read-only or the System attributes of folders in Windows Server 2003, in Windows XP, or in Windows Vista
How can I prevent the file from being deleted?
The file system is NTFS.
It's for protection. The files are for kids' use, and I want to prevent them from deleting the file. (Or, make deleting hard as possible.)
I am looking for a programmatic solution
Deleting a file is a directory change, actually, not a file change. And as noted you can't use attributes, you need full-blown NTFS Access Control Lists (ACL) for that. In particular, what you need is an Access Control Entry (ACE) that
Denies
To Everyone
The right to modify the entire directory
You may optionally prefix another ACE to the ACL with the properties
Allows
To yourself
The right to modify the entire directory
ACE's on an ACL are processed in order, so this prevents you from locking yourself out.
So I'm aware that Amazon S3 doesn't really have directories. My question is: does this make it impossible to reliably get the last-modified timestamp of a "directory" in S3?
I know you can get the last-modified date of a file, as in this question.
I say "reliably" because it would be possible to define the latest last-modified timestamp of a file inside a directory as the last-modified timestamp of the directory. But that's not really accurate, since if a file inside a directory gets deleted, it wouldn't register as a change to that directory (indeed the deletion might cause the last-modified date to go backwards in time).
We're using boto to scrape S3.
If its really important for you to know this, you could develop a solution using the S3 event notifications. Each time a file is put or deleted from a folder you can have either an SNS or Lamba event get fired, and you could use that information to update a table/log someplace where this information is kept for use when you need it.
Probably not a ton of work to do it, but if its critical to know, it is an avenue worth exploring.
http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html
Since what we label as a directory is just part of the object name, there is no creation time, modify time, etc. since it does not really exist as an entity on its own. The object has a path, and when you add '/' to the name, client presentation applications treat that as a separator, split the name, and make it look like a path. Like you suggested, there is no directory, and this is where that concept really is different than a traditional file system and how end users interact with it.
I suggest asking what you are trying to do and why the timestamp of the directory is important. E.J. Brennan suggests what you may be trying to do and is not a bad idea for the case he mentions. There is likely a different way to skin your cat.
I am using visual studio to develop a windows form application in c++ to detect certain anomalies and log it.
The log file that I am intending to create will be of a common format such as .txt. I do not want users of the computer to modify this file that is I want only my program to modify it( I want users to read this file not modify it).
Is there any way to achieve this??
if you want to hide the content from other users then encrypt the file or use a binary format that only your program will be able to understand.
As long as the file resides on a publicly accessible area in the file system, then other users will be able to access it.
You can put the file in a specific user's Documents area, which might go some way to protecting the file from other users of that machine, but not from administrators.
You could even set the file attributes to "hidden" or something along those lines, to further make it hard for people to find it. But a complete access block is difficult (if not impossible).
After all this, you can also use NirMH's method to ensure that even if someone finds and attempts to read the file, then the encryption should make it difficult to crack it open. A binary format can still be read with a hex editor, if someone is really keen to read your file.
I'm currently in the idea phase for a small application that requires keeping track of specific, user chosen files.
I want the system to be intuitive, such that a user can change the file name, directory name, or move the file to a new location, and the application would still be able to keep track of the file.
Now, I know that I can monitor directories already, for the majority of these kinds of changes, with windows system calls.
The problem I'd have is finding if/when a file is cut, copied, or pasted somewhere. I've read a little about shell extensions, but they have actually rather confused me (since I haven't had the time to actually read good and long about them yet). Is there a way I could monitor a file for being cut/pasted/copied, so that my application could continue to track the file in it's new location? Would I have to do this through a shell extension?
You can use shortcut objects to track files even if they are renamed or moved.
There are at least three techniques for detecting if a file exists:
Query the file attributes
Use FindFile() with a specific filename instead of a search pattern
Open the file in read mode and look at any resulting error
All of the above seem to suffer from false negatives. That is, I am told that the file doesn't exist when it actually does due to either glitches in how file-io over a network works, or due to file permissions issues.
I have a customer who can see that a file exists in explorer, delete that file, but is given "access denied" if they try to view that file.
I have been unsuccessful at replicating this exact behavior. But what I can create is a situation where the file exists, but due to restricting permissions on it, I cannot see the file in that folder under my user credentials. That is, GetFileAttributes(), FindFile(), and fopen() return failure, i.e. file not found for that file (but if I look in that same folder under a different account - say a network admin, I can see that the file most certainly exists).
As to how my end user (or anyone) would end up in such situations is opaque to me. I have no concrete ideas - maybe power failure while the file was previously opened, maybe some sort of network glitch causing the file handle to remain locked to a dead process on a foreign PC, ...? I'm just making stuff up because I have no idea what might cause such situations to arise.
However, what I really don't have is the ability to query Windows and know for a fact "does file X exist, or not"
Does anyone know of a technique that will honestly answer that question regardless of the user's permissions (assuming that they're allowed to query the contents of the folder itself - I'm not asking for an unauthorized access scenario - just a "normal" user X can't edit file Y, but still wants to know if file Y exists or not.
Hokay - this is getting bizarre.
Using any of the file detection techniques works so long as I ask twice. The first time always tells me "does not exist". Second+ tells me "yup, it's there, but you can't open it."
The file in question is on a shared folder on a Windows Server 2008 NTFS drive. It is shared for everyone full control. I have manually added an "Everyone Deny Read" ACL to the file, in order to simulate my customers problem. So I have denied read, but no other access, and only to the file, not to the share, or the folder in which this file lives.
(I used Explorer to make this modification, not my own software or a command line utility).
I can see that the file exists from the local admin account on that server. I cannot see that it even exists from my local workstation, logged in as a standard user under Windows 7, UAC enabled, non-elevated explorer / application.
It would appear that if a file's read-access is explicitly denied, that the file is not visible any longer (except to account for which that deny doesn't apply, or to the local admin which has some back-door way to see the file despite that deny ACL).
I have tried FindFirstFile, GetAttributes, CreateFile, _taccess_s, and PathFileExists. In every case, the first attempt to access the file indicates "file not found", but the second attempt in a row results in no-error (file found).
I cannot begin to explain these results. I think at this point I need to run all of my tests locally, to remove network file sharing from the mix. These results just don't make a whole heckuva lot of sense (to me).
fltmc output for the folder, from local admin account on the server:
Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
aksdf 8 145900 0
luafv 1 135000 0
There's a POSIX function named access that does this. It looks like there's a Windows equivalent _access: http://msdn.microsoft.com/en-us/library/1w06ktdy(v=vs.80).aspx
have You trie WinAPI call to CreateFile with second parameter set to 0 ? Here's description: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx and part I point You to is: "If this parameter is zero, the application can query certain metadata such as file, directory, or device attributes without accessing that file or device, even if GENERIC_READ access would have been denied."
If permissions are set up to say "you're not allowed to even look at the name of this file" (e.g., denied you access to the directory it's in), any ability to "see" that file, even to the extent of just confirming or denying its existence is a clear security hole.
As such, there are only a few possibilities that I can see. The most obvious would be to use an Administrator account to search for the file. This will probably annoy the user, as they'll most likely need to enter credentials for that administrative account to use it. For users who don't have access to an Administrator account (most, you'd hope) it simply won't work at all.
Another possibility would be to find and exploit a security hole that lets you do what you want, even though you're really not supposed to be able to. This is (at least) equally problematic -- nearly any hotfix, service pack, etc., might "plug" the security hole you're exploiting, and your code will quit working. Likewise, there's at least a reasonable chance that some sort of anti-malware software might decide (more or less correctly) that your code is being naughty, and tell the user it's doing bad things.
Use the shell function PathFileExists.
An alternative is to mimic what FileExists in Delphi/BCB does, which is to employ FindFirstFile to get the WIN32_FIND_DATA of the file and thus check whether it exists or not.
And by the way, the situation you refer to is completely artificial. It relates to SeChangeNotifyPrivilege which every default installation assigns to even unprivileged users. The user right is called "bypass traverse checking" (in secpol.msc under Security Settings -> Local Policies -> User Rights Assignment) :)
It means that for all practical purposes you should be able to find out if a file exists if you know its path and name.
And yes, Jerry is right, this is a security hole. But a calculated one. Privileges ("user rights") are exactly that: a way to ignore certain permission issues. It's the very purpose of privileges in Windows.