I'm writing some sort of backup tool that has to copy all the files in a directory. Now I'm using C#'s File.Copy(String, String, Boolean) method. But another application (which I can't change) simultaneously writes to the files in that directory.
So now I wonder if it is possible that a file gets changed halfway the copying process creating a corrupt backup file?
Thanks
No, it is not. Underlying file system will make sure this is not happening.
Related
I am using a library to create a PDF file from HTML, then I print that file and delete it from disk. The issue is, we don't want anything stored on disk, not even temporarily. I thought about using some kind of RamDisk, but I see MemoryMappedFile thrown around everywhere. I looked into it, but I don't think that provides the functionality I want since the file should already exist on disk before using it in a MemoryMappedFile.
My question is: Is my assumption true about the file needing to be on disk FIRST before using it in a MemoryMappedFile? IS there a way to create a MemoryMappedFile and access it using a virtual path without it existing on disk?
In case MemoryMappedFile doesn't work, what library can I use to create a virtual RamDisk with C#? It will only be storing 1 file at a time.
As we all know that we can not get the full path of the file using File Upload control, we will follow the process for saving the file in to our application by creating a folder and by getting that folder path as follows
Server.MapPath
But i am having a scenario to select 1200 excel files, not at a time. I will select each and every excel file and read the requied content from that excel and saving the information to Database. While doing this i am saving the files to the Application Folder by creating a folder Excel. As i am having 1200 files all these files will be saved in to this folder after each and every run.
Is it the correct method to follow or not I don't know
I am looking for an alternative solution rather than saving the file to folder. I would like to save the full path of file temporarily until the process was executed.
So can any tell me the best way as per my requirement.
Grrbrr404 is correct. You can perfectly take the byte [] from the FileUpload.PostedFile and save it to the database directly without using the intermediate folder. You could store the file name with extension on a separate column so you know how to stream it later, in case you need to.
The debate of whether it's good or bad to store these things on the database itself or on the filesystem is very heated. I don't think either approach is best over the other; you'll have to look at your resources and your particular situation and make the appropriate decision. Search for "Store images on database or filesystem" in here or Google and you'll see what I mean.
See this one, for example.
I'm trying to find some lost .jpg pictures. Here's a .bat file to setup a simplified version of my situation
md TestSetup
cd TestSetup
md a
cd a
echo "Can we find this later?" > a.abc
del a.abc
cd..
rd a
What code would be needed to open the text file again? I'm actually looking for .jpeg files that were treated in a similar manner
More details: I'm trying to recover picture files from a previous one-touch backup where the directories and files have been deleted and everything was saved in the backup with a single character name and every file has the same 3 letter extension. There is a current backup but they need to view the previous deleted ones (or at least the .jpg files).
Here's how I was trying to approach it: C# code
To the best of my knowledge, most file recovery tools actually read the low-level filesystem format on the disk and try to piece together deleted files. This works because, at least in FAT, a deleted file still resides in the sector specifying the directory (just with a different first character to identify it as "deleted"). New files may overwrite these deleted entries and therefore make the file unrecoverable. That's just a little bit of theory.
There is a current backup but they
need to view the previous deleted ones
(or at least the .jpg files).
Unless there's a backup for that file at the time that you want to restore from, I believe you're going to have a hard time getting that file without resorting to a low-level filesystem read. And even then, you may be out of luck if enough revisions have been made (or it's not a trivial filesystem like FAT).
Is it possible to create a file on a disk which is full??
Does creation of the file take any space??
Basically I am seeing a case where C# has created but failed to write anything whhich I think points to a full disk.
Does anyone know whether creating a file on a full disk will fail or not??
This wa done using c# o Windw xSerevr- The log file was also written to the same drive
Creating (empty) files should still be possible in most cases. The MFT is a separate part of the volume which won't get used for file data.
It should even be possible to store small amounts of data without needing more than the file entry in the MFT. NTFS can store streams as "resident data" in the stream descriptor which doesn't need any additional space, but only works for very small files.
I think your issue is another problem, though. It may be that you have permissions to create a file but not to write anything to it. You might want to check the ACLs of the location where you're trying to write.
I have a database that is locking mdb's and such that I'd like to backup. However the tool (I have the source) I am using opens the file before backing it up and finds that it is locked.
Is there a way I can open it for read-only purposes?
For reference the tool uses C# and .NET 2.0 (but can be updated to 3.5).
The reason your tool locks the file is to prevent changes to the file as it is being backed up. For example, if you begun your backup, but halfway in the DBMS (i.e. SQL Server) decided to make a change to a file, then your backup would be corrupt.
I recommend you use the tools that are provided with your database solutions to perform a backup. The other option is to stop the database before backing it up.
If the DBMS is holding a write lock on the file, and you read it, you're risking the DBMS writing the file as you're reading it. Depending on what part was written, you could end up with a corrupt backup of the file. You're best off reading the file only if the DBMS isn't writing to the file or letting the DBMS handle its own backups.
This is similar to this question:
Opening a file's Shadow Copy if the current copy is in use
It depends on how the database is opening the MDB file. If it's not allowing read sharing then you're out of luck unless you are able to open the shadow copy. There's a discussion on how to do this here:
How do I copy a file or folder that is locked under windows programmatically?